This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Namespace nodes in XSLT and XPath
- To: xsl-list at mulberrytech dot com
- Subject: Re: Namespace nodes in XSLT and XPath
- From: David Carlisle <davidc at nag dot co dot uk>
- Date: Wed, 28 Jun 2000 11:40:48 +0100 (BST)
- CC: xsl-editors at w3 dot org
- References: <20000628190153.C24875@io.mds.rmit.edu.au>
- Reply-To: xsl-list at mulberrytech dot com
> Clearly, from XSLT 7.1.1, the <out> element must have a copy of
> the xmlns="http://www.foo.com/" 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 'http://www.foo.com/' or the namespace 'http://www.bar.com'?]]
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
referenced.
> 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.
David
[I should stress that I am answering from xsl-list not xsl-editors,
as you cross posted]
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list