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

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