[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: xpath union and node set order

• To: "'Tor Helland'" <tor@h...>,<xml-dev@l...>
• Subject: RE: xpath union and node set order
• From: "Michael Kay" <michael.h.kay@n...>
• Date: Sat, 2 Oct 2004 14:38:13 +0100
• In-reply-to: <003101c4a858$2bdc9000$0301a8c0@rhuidean>
• Thread-index: AcSoWGnewXCvmz59R8+2CZncXwp5vgAK3Ygg

Firstly, //b|c and //c|b don't necessarily return the same nodes. The
expression parses as (//b)|c, not as //(b|c).

Secondly, the XPath 1.0 specification defines that a path expression (or a
union expression) returns a node-set, that is, an unordered set of nodes.
Some host languages, for example XSLT 1.0, specify that node-sets are always
processed in document order. But you appear (as far as I can tell) to be
invoking XPath from some Microsoft API, and I've no idea what that API says
about the processing order: it's up to the XPath host language to define it,
or it could choose to leave it undefined.

This changes in XPath 2.0, which specifies that path expressions and union
expressions return a sequence of distinct nodes in document order.

Michael Kay
http://www.saxonica.com/
 

> -----Original Message-----
> From: Tor Helland [mailto:tor@h...] 
> Sent: 02 October 2004 09:17
> To: xml-dev@l...
> Subject:  xpath union and node set order
> 
> Hi, I'm looking for an answer to this question:
> 
> Am I right in saying that both these paths should return nodes in the
> same order?
> 
> //b|c
> //c|b
> 
> on this document:
> <root><a/><b/><c/><d/></root>
> 
> and that the order should be the document order:
> b
> c
> 
> Or is the order something I can't count on?
> 
> I'm using a DOM, and xpath through the msxml-like interface method
> IDomNodeSelect.selectNodes. And that particular DOM returns 
> the node set for
> "//c|b" in this order:
> c
> b
> 
> I found a couple of things in the spec that may be relevant, 
> listed below.
> [2] says the node set is unordered, so it is implementation 
> dependent. [1]
> and [3] are very specific on document order - [1] when used with a
> predicate, [2] regarding proximity position.
> 
> Is there a difference between the finally resulting node set 
> and the node
> set in the expression? I would think the resulting node set 
> should be like
> the second part of the example in [1], using the child axis, 
> and in document
> order.
> 
> [4] says I have to specify an ordered node set, or I will get 
> an unordered
> on. IDomNodeSelect.selectNodes does not follow [4], but it 
> does suggest that
> I can't rely on document order.
> 
> With [1] and [3] being very specific about document order, I get the
> impression that it it allowed to scramble the node set order before
> delivering the results ;-)
> 
> I based some code on the assumption that I would always get 
> document order.
> If I'm right, I'll file a bug report for the DOM, and maybe 
> fix it. If not,
> my code is rather flawed. I'll have to fix either the DOM or 
> my code...
> 
> -tor
> 
> Bits from the spec (http://www.w3.org/TR/xpath):
> 
> [1] Section 3.3
> The meaning of a Predicate depends crucially on which axis 
> applies. For
> example, preceding::foo[1] returns the first foo element in 
> reverse document
> order, because the axis that applies to the [1] predicate is 
> the preceding
> axis; by contrast, (preceding::foo)[1] returns the first foo 
> element in
> document order, because the axis that applies to the [1] 
> predicate is the
> child axis.
> 
> [2] Section 1
> node-set (an unordered collection of nodes without duplicates)
> 
> [3] Section 2.4
> The proximity position of a member of a node-set with respect 
> to an axis is
> defined to be the position of the node in the node-set 
> ordered in document
> order if the axis is a forward axis and ordered in reverse 
> document order if
> the axis is a reverse axis.
> 
> And from DOM Level 3 XPath
> (http://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/DOM
3-XPath.html):
> [4] Section 1.4
> If the natural result is a node set when ANY_TYPE was requested, then
> UNORDERED_NODE_ITERATOR_TYPE is always the resulting type. Any other
> representation of a node set must be explicitly requested.
> -------
> 
> 
> -----------------------------------------------------------------
> 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://www.oasis-open.org/mlmanage/index.php>
> 

• Follow-Ups:
  • Re: xpath union and node set order
    • From: "Tor Helland" <tor@h...>

• References:
  • xpath union and node set order
    • From: "Tor Helland" <tor@h...>

• Prev by Date: xpath union and node set order
• Next by Date: Re: xpath union and node set order
• Previous by thread: xpath union and node set order
• Next by thread: Re: xpath union and node set order
• Index(es):
  • Date
  • Thread