[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 Friday, 16 May 2003 00:27:25 UTC