RE: [F&O] Casting QName to xs:String

Thank you for your comment.  The WGs decided to accept your
recommendation and prohibit casting QName to string.  Your futher
recommendation in 
http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0046.htm
l
that a function to cast QName to string need not, perhaps should not be
provided was also accepted.

All the best, Ashok

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Kay, Michael
> Sent: Thursday, May 15, 2003 9:26 PM
> To: public-qt-comments@w3.org
> Subject: [F&O] Casting QName to xs:String
> 
> 
> This is a last call comment derived from implementation experience.
> 
> In the most recent draft, we introduced the capability to cast a QName
to
> a
> string, using the in-scope namespaces from the static context to map
the
> URI
> to a prefix.
> 
> To implement this, the processor needs to have available at run-time
the
> full set of namespace declarations from the static context. In
principle
> this is acceptable, there are other situations where this is also
needed,
> especially in XSLT. However, there is a big problem in this case: the
> processor cannot always detect statically that the value will be a
QName.
> If
> the static type can only be inferred as (say) item() or node(), then
the
> processor must copy the namespace context into the run-time
environment
> just
> in case the value (after atomization) turns out to have a dynamic type
of
> QName. This is especially painful for XSLT processors that produce
> compiled
> code.
> 
> This is a heavy price to pay, and contravenes the principle that
> infrequently used facilities should not impose a performance cost on
paths
> that are executed much more frequently.
> 
> I propose that we should revert to the previous situation:
> 
> * conversion of a QName to a string should be done using a
special-purpose
> function: resolve-QName() with a single argument
> 
> * casting of QName to string should be an error
> 
> The use of the resolve-QName() function can always be detected
statically,
> so the copying of the namespace context needs to be done only in a
> situation
> where the information is actually needed.
> 
> At first sight this is burdensome for the user, it means they cannot
do
> something like
> 
>     <xsl:value-of select="$param"/>
> 
> and have it work in the case where $param is a QName. However, the
casting
> of QNames to strings needs special care anyway, because there is no
> guarantee that the relevant namespace is declared in the static
context.
> 
> Michael Kay
>

Received on Tuesday, 30 September 2003 16:58:45 UTC