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

On Monday, Oct 27, 2003, at 13:23 Europe/Berlin, Kay, Michael wrote:

> > > with reference to:
> > >
> > > 17.14 casting to xs:Qname
> > >
> > > what is the use case for casting from a string to a universal name.
> >
> > We have decided to remove this functionality, it will
> > disappear in the next draft.
> > >
> >
> Sorry, I have to correct myself here. We have removed the ability to 
> cast an xs:QName to a string, but not the ability to cast a string to 
> an xs:QName.
>
> The differences between the two cases are:
>
> (a) although both involve the need to keep the static namespace 
> context for use at run-time, in the case of string-to-QName you know 
> statically that you are going to need this, whereas in the case of 
> QName-to-string you often don't know statically whether the input will 
> be an xs:QName or not, so you have to keep the namespace context "just 
> in case".

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.

>
> (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.

...

Received on Monday, 27 October 2003 08:22:43 UTC