9808 2010-05-26 15:37:30 +0000 [FO] fn:QName $paramUri need not be a valid xs:anyURI 2012-03-27 23:25:41 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 1.0 Recommendation PC Windows NT CLOSED FIXED http://www.w3.org/TR/xquery-operators/#func-QName P2 normal --- 1 tim mike public-qt-comments oldest_to_newest 35837 0 tim 2010-05-26 15:37:30 +0000 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 := 'http://www.example.com/%gg/this-is-not-an-anyURI' return (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. 35839 1 mike 2010-05-26 21:59:50 +0000 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. 35841 2 tim 2010-05-27 08:04:15 +0000 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? 35842 3 tim 2010-05-27 10:01:33 +0000 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. 37252 4 tim 2010-08-05 12:39:48 +0000 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. 39285 5 mike 2010-09-24 14:28:26 +0000 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 42715 6 mike 2010-11-23 10:18:17 +0000 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. 66155 7 mike 2012-03-27 23:25:41 +0000 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.