On 08-03-08, at 09:10, Mark J. Reed wrote:
The difference is, I think, between "XPath" itself and "a node set returned by an XPath _expression_". XPath itself will, depending on the chosen axis, iterate over the document in a specified order, including the document order, but if a predicate returns a "node set", then that result is inherently unordered (and without duplicates).
This means to me (as an _expression_ in XSLT) that in the node-set returned by:
<xsl:apply-templates select="@* | comment() | processing-instruction()"/>
there's no guarantee that attributes and comments will be ordered before PIs. That's because the type of nodes returned in this call are different from each other. These specs generally define implementation requirements more than usage. So for instance the above call done Saxon (written in Java) may return {comments, attributes, PIs} but libxslt (written in C) may return {PIs, comments, attributes} to the calling application. It is up to the calling application to then interpret that resulting node-set in the current context. That is, in the case of an XSL stylesheet, it processes the node-set according to the way the input template rules are defined.
However in:
<xsl:apply-templates select="//foo"/>
A select attribute can be used to process nodes selected by an _expression_ instead of processing all children. The value of the select attribute is an _expression_. The _expression_ must evaluate to a node-set. The selected set of nodes is processed in document order, unless a sorting specification is present (see [10 Sorting]).