This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The function conversion rules stipulate that when an untypedAtomic value is supplied by the caller, it is cast to the required type given in the function signature. If the required type is namespace-sensitive (e.g. QName) this is probably a bad idea. In 2.0 the cast would fail (the cast could only succeed if the supplied argument were a string literal, in which case it would not be untypedAtomic). In 3.0 it's not obvious whether the cast should be done using the namespaces from the static context of the caller or that of the callee; in fact, neither is at all appropriate, since an untypedAtomic value is almost certainly derived by atomizing an untyped attribute such as xsi:type, and the only appropriate namespace context to use is that of the node that was atomized. So I propose changing the function calling rules so the cast from untypedAtomic to the expected type does not happen if the required type is namespace-sensitive (that is, QName, NOTATION, or a type derived therefrom, or a union type with such a type in its membership).
While on the subject of casting to QName, it occurs to me that one might expect cast @xsi:type to xs:QName to use the namespace context of the xsi:type attribute node, rather than the static context of the query. In fact, using the static context of the query here seems distinctly wrong. There are two things we could do, both involving some sacrifice of orthogonality (though not as severe a departure as the rule about string literals in 2.0): (a) ban atomization of the operand of cast|castable if the target type is namespace-sensitive (b) use a customized variation of the atomization rules for the operand of cast|castable, whereby if the operand is a node and the target type is namespace sensitive then the namespace context used is that of the node. (This is similar to the behaviour of the document() function in XSLT, which uses the base URI of the supplied node when the argument is a node, before atomizing it as normal).
(In reply to comment #1) > While on the subject of casting to QName, it occurs to me that one might expect > cast @xsi:type to xs:QName > to use the namespace context of the xsi:type attribute node, rather than the > static context of the query. In fact, using the static context of the query > here seems distinctly wrong. There are two things we could do, both involving > some sacrifice of orthogonality (though not as severe a departure as the rule > about string literals in 2.0): > (a) ban atomization of the operand of cast|castable if the target type is > namespace-sensitive > (b) use a customized variation of the atomization rules for the operand of > cast|castable, whereby if the operand is a node and the target type is > namespace sensitive then the namespace context used is that of the node. (This > is similar to the behaviour of the document() function in XSLT, which uses the > base URI of the supplied node when the argument is a node, before atomizing it > as normal). I agree that these two are the right options, but I am strongly favoring option (a). I think it makes little sense supporting this and having to carry around all in-scope namespaces for every node for such a rare and meaningless query seems like too much overkill.
The Query Working Group has adopted comment #0 and comment #1, proposal (a).
For the record, I have added tests Cast674 and Cast675 to test for these conditions.