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

xpath union and node set order

• To: <xml-dev@l...>
• Subject: xpath union and node set order
• From: "Tor Helland" <tor@h...>
• Date: Sat, 2 Oct 2004 10:16:49 +0200
• Organization: helland.org

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/DOM3-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.
-------

• Follow-Ups:
  • RE: xpath union and node set order
    • From: "Michael Kay" <michael.h.kay@n...>

• Prev by Date: RE: Ted Nelson's "XML is Evil"
• Next by Date: RE: xpath union and node set order
• Previous by thread: RE: [Fwd: Not-entirely-OT: XSLT theme song?]
• Next by thread: RE: xpath union and node set order
• Index(es):
  • Date
  • Thread