Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] xpath union and node set order

From: "Michael Kay" <michael.h.kay@--------.--->
To: "'Tor Helland'" <tor@-------.--->,<xml-dev@-----.---.--->
Date: 10/2/2004 1:38:00 PM
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: [xml-dev] 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>
>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent