RE: WD-xpath-functions-20030502: casting xs:QName

> 
> this is ironic, as in exactly the case of QName-to-string 
> there is, in 
> fact, no necessity to afford the lexical context a dynamic extent, as 
> it is always possible to fabricate the prefixes and namespace nodes 
> during the serialization.

Not as currently defined. One could try to define a QName-to-string
conversion that has the side-effect of fabricating a prefix and creating a
namespace node in the context where the string is going to be used. But that
isn't how QName-to-string casting is defined in the current draft, and this
revised definition would be so complex that we've avoided doing it. In
particular, it wouldn't be a standard cast, because it needs some kind of a
handle on a node where the QName is used.
> 
> >
> > (b) it is easier to come up with plausible use cases for casting
> > string to xs:QName,
> 
> please. do.
> 
> >  although it's true that it's only a convenience mechanism: 
> since the
> > query author has to know what the namespace bindings are, 
> they could 
> > have constructed the expanded QName directly from the URI and local 
> > name.
> 
> if we agree that is seen as a convenience mechanism only, please 
> elaborate on the utility of a convenience mechanism which will 
> ultimately cause combination operations to fail.
> 
Namespace prefixes are indeed a convenience mechanism, and they do indeed
have the effect that cut-and-paste operations on fragments of XML may fail.
This design decision has been made, and it's outside our scope to change it.
What we have to do is to come up with a design for handling namespaces in
XQuery that is as consistent as possible with the way that XML namespaces
already work. Yes, life would be much cleaner if namespace prefixes didn't
exist, and users always had to use URIs. Unfortunately, we can't uninvent
them.

Michael Kay