[
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
parent)
(ancestor::node())[1] gets the first ancestor in document order (the root
node)
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
order.
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,
Evan
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
amyzing@talsever.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>
>
>
|
