RE: xsl transforming xsl

> In fact, there is currently no rule that says the XSLT 
> processor (or any other kind of XML processor for that 
> matter) has to honour the prefix you use.  It just has to 
> make sure the namespace is correct.
> 
> I believe XSLT 2.0 changes this, because there is a bit of a 
> problem in that namespace prefixes can also apear inside 
> attribute values - as they do in XPath used within XSLT.

No, there's no real change here, though there's some clarification.

In XSLT 1.0, namespace prefixes are retained as part of namespace nodes,
but not as part of element and attribute nodes. When you copy a
namespace node (for example, because you copied an element) the
namespace prefix must be preserved in the copy, and when you serialize,
a namespace declaration with this prefix must be output. When you
serialize an element, the serializer has to choose a prefix. If there
are several namespace nodes with the same namespace URI, it can choose
any of the prefixes, and if there are none, it must invent one.
Theoretically an XSLT 1.0 serializer is also allowed to add arbitrary
namespace declarations to the result on its own whim, so in it would be
technically legal for an identity transformation to copy

<a:x xmlns:a="some.uri"/>

as

<q:x xmlns:a="some.uri" xmlns:q="some.uri" xmlns:surprise="bonus.uri"/>

But it's rather unlikely that any real XSLT processor would go to the
trouble.

The real case where prefixes are unpredictable is if there are multiple
namespace nodes with the same namespace URI. This can arise as a result
of <xsl:namespace-alias>, or it can arise when you copy an element from
the source document and another element from the stylesheet, if the
source document and stylesheet use different prefixes for the same URI.
In this case the processor will output namespace declarations for both
prefixes, and it can use either of them in element and attribute names
(and in the result of the name() function - though name() in XPath 1.0
is grossly underspecified).

In XSLT 2.0 this is tightened up in two ways. Firstly, where extra
namespaces need to be generated, this is done at the tree construction
stage, not by the serializer (this is significant because unlike XSLT
1.0, you can now "look inside" constructed trees). Secondly, there are
rules preventing the namespace fixup process inventing new namespaces on
a whim, though it still has some flexibility on how to resolve
conflicts.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list