This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For casting a string to a QName, we have a special rule that the string must be written as a string literal. It's not clear how this rule affects the "castable" expression. As written, V castable as xs:QName is true if the *value* V can be cast to a QName; the spec says nothing about the result depending on the way in which V is written. The "least surprise" option is probably to say that V castable as xs:QName (when V is a string) can succeed only if V is written as a string literal. Michael Kay
Considering the new wording in: http://www.w3.org/Bugs/Public/show_bug.cgi?id=2678 more specifically: "It is also permitted for these constructors and casts to take a dynamically-supplied argument in the normal way, but as the casting table (see section 17) indicates, the only arguments that are supported in this case are values of type xs:QName or xs:NOTATION respectively." it makes me wonder what's the least surprise here, since casting a xs:QName would also be valid, as I see it. Since the texts in this area deals with the casting on a sometimes grammatical level, one should perhaps watch out such that the empty sequence doesn't get disallowed. E.g, the texts should gracefully handle "() castable as xs:QName?" and "() cast as xs:QName?", in the appropriate way. Frans
Mike, The Query and XSLT working groups discussed your issue on June 6, 2006, and agreed to add the following Note to the section on the "castable" expression: If the target type is QName or NOTATION or derived from one of these, and the input argument is of type xs:string but it is not a literal string, the value of the "castable" expression is False. Since you were present during the discussion of this issue, I am marking this Bugzilla entry as Fixed and Closed. Regards, Don Chamberlin