Re: [XQuery] IBM-XQ-022: Casting QName to string

Michael,

already casting strings to Qname uses the in-scope namespaces,
in a scope-dependent manner.

Do you think making the casting in the other direction working in the
same way is unacceptable ? Just pick randomly a prefix from the inscope
namespaces with the given URI (if any) or invent one in an 
implementation
dependent manner.

We can leave the task to make sure that the right NS is in scope in the 
place
where the string is used to the user in V1.

I know it is not 100% acceptable, but it would allow us to write 
queries that
we cannot for the moment.

In the meantime, I would ask XML Schema to support the Clark's notation.

Best regards,
Dana




On Feb 17, 2004, at 6:57 AM, Michael Kay wrote:

> So, what semantics do you propose for casting QNames to strings?
>  
> Remember that when we did allow such casts, they only worked for a 
> very small number of QNames, namely those whose URI matched the URI of 
> a namespace declaration in the query. I would dearly like it to be the 
> case that all atomic values can be converted to strings, but having a 
> rule that a small number of QNames can be cast to strings does not 
> seem a great step forward.
>  
> Note that during serialization, any conversion of a QName to a string 
> should be done in the context of the namespaces declared in the 
> document being serialized. It's hard to see how this contextual 
> information can be made part of the casting operation, which takes a 
> single atomic value as its input.
>  
> One possible way forward is to invoke a winged dragon. We simply say 
> that when a QName is cast to a string, the system chooses any prefix 
> it fancies. Sometimes the system will be able to choose a prefix that 
> makes sense; if it can't, then the user is going to get an "undeclared 
> namespace" error at some point, which is no worse than the current 
> situation. In some scenarios (at least in XSLT which allows computed 
> namespace nodes) the user will be able to examine the prefix that the 
> system has chosen and generate a namespace declaration for it.
>  
> Michael Kay
> -----Original Message-----
> From:public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org]On Behalf Of Don Chamberlin
> Sent: 17 February 2004 04:44
> To:public-qt-comments@w3.org
> Subject:[XQuery] IBM-XQ-022: Casting QName to string
>
>
> (IBM-XQ-022) The following parts of the XQuery document depend on the 
> ability to cast any atomic value into a string:
> (a) Section 3.7.1.1, Direct Element Constructors--Attributes, Rule 3b.
> (b) Section 3.7.1.3, Direct Element Constructors--Content, Rule 1d.
> (c) Section 3.7.3.1, Computed Element Constructors, Content Expression 
> Rule 1.
> At present, the Functions and Operators document does not permit a 
> QName to be cast into a string. It is clearly not acceptable to be 
> unable to construct any element or attribute that contains a QName. 
> This inconsistency between the XQuery and Functions and Operators 
> documents needs to be corrected.
>
> Note that casting a QName into a string is also required by the 
> Serialization document, as noted in comment IBM-SE-015.
>
> --Don Chamberlin