Re: [xsl] Axis order and variables

[David Carlisle <davidc@xxxxxxxxx>]

> 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