Re: XPath node-set order
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() gets the first ancestor in reverse document order (the parent) (ancestor::node()) 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@t...> To: <xml-dev@l...> Sent: Thursday, December 13, 2001 1:32 PM Subject: 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@m... amyzing@t... > 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> > >
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format