This area is a total minefield.

First, the rules for exactly what is allowed in an xs:anyURI are far from clear. XSD 1.1 gives up on this, and says any sequence of Unicode characters is allowed.

Secondly, the namespaces specs (both 1.0 and 1.1) are not prescriptive about exactly what's allowed in a namespace name ("URI"). They talk about it being a URI/IRI respectively, but they never say that a document is ill-formed if the namespace name isn't a valid URI/IRI. So parsing a well-formed document can produce an XDM model in which there are namespace names that are not valid URIs.

To further muddy the waters, xs:anyURI allows relative URI references, which are strongly deprecated as namespace names, but nevertheless legal.

For these reasons, the XQuery spec states in regard to URILiterals (as used in namespace declarations) that "However, an implementation MAY raise a static error [err:XQST0046] if the value of a URILiteral is of nonzero length and is not in the lexical space of xs:anyURI." - that is, it's up to implementations how much checking to do, and what rules to enforce. With XSD 1.1, there are no restrictions left to enforce.

At the most, fn:QName should be permissive about the checking that is done, along the same lines as the rules for URILiteral in XQuery.

Would you therefore suggest changing the signatures of

fn:namespace-uri-from-QName($arg as xs:QName?) as xs:anyURI

fn:namespace-uri-for-prefix($prefix as xs:string?, 
                            $element as element()) as xs:anyURI?

fn:namespace-uri() as xs:anyURI

and

fn:namespace-uri($arg as node()?) as xs:anyURI

to return xs:string or xs:string? as appropriate?

Interestingly, this is an area where XSLT and XQuery differ in their behaviour.  I note that XSLT specifically bothers to check the namespaces for xsl:element, xsl:attribute and xsl:namespace instructions.

ERR XTDE0835

    It is a non-recoverable dynamic error if the effective value of the namespace attribute [of the xsl:element instruction] is not in the lexical space of the xs:anyURI data type.

There is also a related issue in fn:base-uri.

declare base-uri 'http://www.example.org/';

let $x := <x xml:base="%gg" />
return base-uri($x)

In XQuery 1.0: An XML Query Language, 3.7.1.3 Content

# base-uri is set to the following value:

   1.      If the constructed node has an attribute named xml:base, then the value of this attribute, resolved if it is relative against the base URI in the static context. The value of the xml:base attribute is normalized as described in [XML Base].
   2.      Otherwise, the value of the base URI in the static context.

I can't put my finger on anything in XQuery which says that 

declare base-uri 'http://www.example.org/';

<x xml:base="%gg" />

will raise an error before we hit the call to base-uri.

I propose to bring F+O into line with XQuery by stating: 

"If <code>$paramURI</code> is not a valid URI (XML Namespaces 1.0) or IRI (XML Namespaces 1.1) then an error <rfc2119>may</rfc2119> be raised <errorref class="CA" code="0002"/>."

Michael Kay

The working group has actioned me to close this (A-451-02) with the resolution described in comment #5.

I recognize that this is only a local fix; the general problem of deciding whether and when we enforce URI-validity is not going to go away easily. If the current situation is unsatisfactory, it's not for want of effort.

I note that the agreed change appears in the draft F+O 3.0 specification, but not in the 1.0/2.0 Second Edition. I have added a reference to this bug to the candidate errata list for any future issue of the 1.0/2.0 specification (in the xsl-query-specs CVS area), and having done so, I am now marking the bug as closed.