This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Casting NOTATION to String. Section 17.1.2 says: If ST is xs:QName or xs:NOTATION: * if the qualified name has a prefix TV is (fn:concat(fn:prefix-from-QName( SV), ":", fn:local-name-from-QName( SV)). A literal reading of this says that if the NOTATION has a prefix, the result is a type error, because fn:prefix-from-QName() cannot be applied to a NOTATION. I don't think this is the interpretation that is intended. Since this expression cannot be written in XPath, I suggest rephrasing it as "if the qualified name has a prefix TV is the concatenation of the prefix of SV, a single colon (:), and the local name of SV". For the future: it seems unsatisfactory that the only way of constructing a NOTATION is from a literal string, and that there is no way of processing a NOTATION other than converting it to a string. This makes it impossible for the user to determine, for example, what namespace a NOTATION is in, or to ensure that this namespace is declared when an attribute of type NOTATION is written to the result tree. I suggest that we should allow casting between QName and NOTATION in both directions, with the obvious semantics, making operations defined on QNames available for constructing and deconstructing NOTATIONs.
A separate problem, but I'll include it under the same bugzilla entry for convenience. When converting from a string to an xs:QName or xs:NOTATION, both the language book and F+O make it clear that the value must be supplied as a string literal. However, neither says how the conversion is actually done: specifically how the namespace context is determined. I think we all know that the unstated intent is to use the in-scope namespace bindings from the static context of the expression. But what URI is used when there is no prefix? Should the null namespace be used, or does the default namespace for elements and types apply? Despite the fact that the name is neither an element nor a type, I think this default probably should apply, as this is the rule that is closest to the semantics of schema validation.
The future enhancement suggestion (casting between QName and NOTATION) has been moved to bug #4901. The other suggestions were discussed by the WG on 29 July 2007 and accepted. The problem raised in "comment 0" has been raised as erratum E10. Concerning comment #1, it turns out that the spec does actually describe the process of casting from a string literal to a QName or NOTATION; it is described not in section 17.1.1, but in section 5.3. I will therefore raise an editorial erratum E11 that adds a cross-reference to 5.3 from the relevant paragraph in section 17.1.1.
The enhancement proposed in comment #0 has now been transferred to a new enhancement bug entry bug #5270. This bug can therefore now be closed.