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

Re: xpath union and node set order

• To: <xml-dev@l...>
• Subject: Re: xpath union and node set order
• From: "Tor Helland" <tor@h...>
• Date: Sat, 2 Oct 2004 23:32:17 +0200
• Organization: helland.org
• References: <20041002133733.HSHB28875.mta01-svc.ntlworld.com@Turtle>

Thanks. This was good, solid information.
Yes, I was unsteady with my example xpaths. My actual code didn't use the
"//". It was simple one-level a|b|c.
The main question answered: I hoped it would not be implementation
dependent, but I was wrong.
It's good to hear that the behaviour I hoped for is in the next version.
Makes the world fit together...

Now I've got misunderstandings to work on in my code.

-tor

Michael Kay wrote:
> 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.

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

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

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