OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath node-set order

[ Lists Home | Date Index | Thread Index ]

Amy Lewis wrote:
> So, a node set is an unordered set, in
> which order is implicitly required by other elements of the
> specification.

Document order, reverse document order, hierarchical order, etc. can always
be derived from a set of nodes, because where the nodes come from in the
document is a built-in property of their identity. Actually, the reverse
axes (though pretty funnily specified) are good examples of the fact that
node-sets are indeed unordered.

<xsl:for-each select="ancestor::*"> iterates over the supplied node-set in
document order. Once the expression is evaluated, a node-set is returned and
the implementation is free to forget that the ancestor axis was ever used.
This information is certainly not accessible to the user, e.g. after the
node-set has been bound to a variable.

Compare the following two examples:

ancestor::node()[1] gets the first ancestor in reverse document order (the
(ancestor::node())[1] gets the first ancestor in document order (the root

This is syntactically possible because the Predicate production appears in
the grammar in two places--one as part of a Step and the other as part of a
FilterExpr. In the former case, the predicate is a syntactic component of
the primitive expression Step. In other words, it is not as if
ancestor::node() is evaluated before the predicate is applied. In the latter
case, however, that's exactly what happens. A FilterExpr consists of a full
expression followed by a predicate. In this case, ancestor::node() is
evaluated first (returning an unordered node-set); then the predicate is
applied to the resultant node-set, returning the first member in document

Having said all this, it's certainly possible to redefine the concepts we
use (node-set vs. ordered sequence) without necessarily changing the
behavior of those expressions (particularly in the context of, say, XSLT). I
mention this because XPath 2.0 deals with sequences rather than sets, which
will soon become clear.

Hope this helps,

Step: http://www.w3.org/TR/xpath#NT-Step
FilterExpr: http://www.w3.org/TR/xpath#NT-FilterExpr

----- Original Message -----
From: "Amy Lewis" <amyzing@talsever.com>
To: <xml-dev@lists.xml.org>
Sent: Thursday, December 13, 2001 1:32 PM
Subject: [xml-dev] XPath node-set order

> Hmm.
> Appears that I'm wrong.  According to the spec (very *early* in the
> spec, when the concept of node-sets is introduced), it is stated very
> clearly that node-sets are unordered.
> On the other hand, since the position predicate can be used on almost
> anything, and the position predicate depends upon the axis, my earlier
> statements hold, from a practical perspective.  If you're implementing
> anything that can handle positional predicates, then you have to keep
> track of document order, and have to resolve the positional predicate
> based on the controlling axis.  So, a node set is an unordered set, in
> which order is implicitly required by other elements of the
> specification.
> I'm sure there must be a reason for that.  But it seems clear enough
> that in order to handle further predicates acting on a node-set, that
> the order of the nodes as encountered must be preserved.
> Amy!
> --
> Amelia A. Lewis          alicorn@mindspring.com
> Money can't buy happiness, but poverty can't buy *anything*.
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS