I don't get it. I understood that a nodeset had an inherent ordering
which was established at the time we do the select on the nodeset...
No if it had an inherent ordering it would be called a list or a
sequence not a set. Note Xpath 2 does use sequences as primitive.
Xpath 1 uses sets. "Node set" is not a tye in Xpath 2 drafts.
<xsl:variable name="x" select="ancestor::x"/>
<xsl:value-of select="$x[1]/@n"/>
is equivalent to
<xsl:value-of select="(ancestor::x)[1]/@n"/>
the expression (ancestor::x) returns the set of all ancestors,
the predicate 1 takes teh first element of that set in doc order,
but note the ordering is a feature of teh [1] operation not of the
result of the (ancestor::x) expression.
If we then select nodes from within that nodeset using
another axis, we go back to the document ordering associated with that
axis.
Thanks for the clarification (hope I understand correctly now though).
No. you are making it too complicated, there is no "going back"
sets are unordered.
Your intuition may have expected an ordering for
<xsl:variable name="x" select="ancestor::x"/>
but what would your intuition say for
<xsl:variable name="x" select="ancestor::x|key('a','b')|child::z"/>
<xsl:value-of select="$x[1]/@n"/>
?
Fortunately you don't have to have to guess this as the answer is that
select="ancestor::x|key('a','b')|child::z" returns an unordered set of
all of the selected nodes.
David
________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list