This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9808 - [FO] fn:QName $paramUri need not be a valid xs:anyURI
Summary: [FO] fn:QName $paramUri need not be a valid xs:anyURI
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2010-05-26 15:37 UTC by Tim Mills
Modified: 2012-03-27 23:25 UTC (History)
0 users

See Also:


Description Tim Mills 2010-05-26 15:37:30 UTC
Given the declarations from F&O:

fn:QName($paramURI as xs:string?, $paramQName as xs:string) as xs:QName

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

consider the query

let $uri := ''
  (fn:namespace-uri-from-QName(fn:QName($uri, 'my:name')), 
   $uri castable as xs:anyURI)

fn:QName appears to do no checking that its first argument ($paramURI) is castable as xs:anyURI.
Comment 1 Michael Kay 2010-05-26 21:59:50 UTC
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.
Comment 2 Tim Mills 2010-05-27 08:04:15 UTC
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


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

to return xs:string or xs:string? as appropriate?
Comment 3 Tim Mills 2010-05-27 10:01:33 UTC
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.


    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.
Comment 4 Tim Mills 2010-08-05 12:39:48 UTC
There is also a related issue in fn:base-uri.

declare base-uri '';

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

In XQuery 1.0: An XML Query Language, 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 '';

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

will raise an error before we hit the call to base-uri.
Comment 5 Michael Kay 2010-09-24 14:28:26 UTC
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
Comment 6 Michael Kay 2010-11-23 10:18:17 UTC
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.
Comment 7 Michael Kay 2012-03-27 23:25:41 UTC
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.