This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Future enhancement request, extracted from bug #4874 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.
*** Bug 5270 has been marked as a duplicate of this bug. ***
ACTION-A-392-12 invited me to produce a proposal to resolve this. The proposal is as follows (using the XSLT 2.0 specification as the baseline): 1. No change is needed to section 5.3 (Constructor functions for xs:QName and xs:NOTATION) 2. In the table in 17.1, change the entry for QName->NOTATION to "M" (maybe), and that for NOTATION->QName to "Y". 3. In 17.1.1 (Casting from string) in the paragraph starting "Casting is permitted from xs:string literals to xs:QName and types derived from xs:NOTATION...", delete the word "respectively". 4 Add a new section 17.1.9 Casting to xs:QName and xs:NOTATION Casting from xs:string or xs:untypedAtomic to xs:QName or xs:NOTATION is specified in section 17.1.1. It is also possible to cast from xs:NOTATION to xs:QName, and from xs:QName to any type derived by restriction from xs:NOTATION. (Casting to xs:NOTATION itself is not allowed, because xs:NOTATION is an abstract type.) The resulting xs:QName or xs:NOTATION has the same prefix, local name, and namespace URI parts as the supplied value.
This would also require changes to the XQuery and XPath specifications. Using XQuery 1.0 as a baseline, at least the following would need to be changed: 3.12.3 Cast If the target type of a cast expression is xs:QName, or is a type that is derived from xs:QName or xs:NOTATION, and if the base type of the input is not the same as the base type of the target type, then the input expression must be a string literal [err:XPTY0004]. "must be a string literal" => "must be a string literal or a QName" 3.12.4 Castable If the target type of a castable expression is xs:QName, or is a type that is derived from xs:QName or xs:NOTATION, and the input argument of the expression is of type xs:string but it is not a literal string, the result of the castable expression is false. "is not a literal string" => "is not a literal string or a QName" Other changes may be required in these documents, these are the only two I saw.
Re comment #3: 3.12.3 (cast as) The proposed change to 3.12.3 is not quite right, because it would disallow casting NOTATION to QName (which is the whole point of the change). Instead I suggest changing and if the base type of the input is not the same as the base type of the target type to and if the base type of the input is xs:string 3.12.4 (castable as) No change to this section is needed. The current wording already makes clear that the restriction to string literals only applies when the argument is a string.
In their meeting #402 on 2009-06-09, the WGs accepted the proposal in the comments contained in this bug report. Consequently, I am marking the bug RESOLVED FIXED. If you agree that this resolves your issue, please mark the bug CLOSED.
Since the new functionality is agreed and text is present in the current editor's draft, I am marking this closed.