Re: Namespace nodes in XSLT and XPath

Subject: Re: Namespace nodes in XSLT and XPath
From: David Carlisle <davidc@xxxxxxxxx>
Date: Wed, 28 Jun 2000 11:40:48 +0100 (BST)
> Clearly, from XSLT 7.1.1, the <out> element must have a copy of
> the xmlns=""; namespace node. However, the
> first example would suggest that so, too, should the <foo> element...

> [[Note that they are *not* equivalent, as far as XPath is concerned.
> Consider count()-ing the namespace axis;

Actually they are equivalent as namespace nodes do not correspond to
explicit namespace declarations in the source file, they are copied
to all descendent nodes while the input tree is being constructed.

> What would '//foo/namespace::*[2]' identify?
> The namespace '' or the namespace ''?]]

as is the case for attribute nodes, an implementation has to order
namespace nodes, but the ordering is implementation specific,
so you might get either one.

> From where are the namespace nodes taken when pasting a variable into a
> tree? From the original context? from the context from which the variable
> is pasted? For example, consider

the original context, the element nodes that are in the variable
have namespace nodes, and they don't change when the variable is

> which seems to involve examining the dynamic context in which the variable
> is pasted in order to determine which namespace nodes to insert into
> the result tree...

No the namespace nodes are fixed but a system can, as part of the XML
serialisation in the XML output method, choose to place the namespace
declarations high enough up the output document that they don't need to
be repeated. Note that if the namespace declaration is higher up the
document then parsing the linearised document will produce a different
tree than the original result tree (less namespace declarations implies
more namespace nodes, usually)

but this is explicitly allowed by xslt 16.1:

     In addition, the output should be such that if a new tree was
     constructed by parsing the wrapper as an XML document as specified
     in [3 Data Model], and then removing the document element, making
     its children instead be children of the root node, then the new
     tree would be the same as the result tree, with the following
     possible exceptions:

        The order of attributes in the two trees may be different.

        The new tree may contain namespace nodes that were not present
        in the result tree.

[I should stress that I am answering from xsl-list not xsl-editors,
 as you cross posted]

 XSL-List info and archive:

Current Thread