Re: constructing the Node Sets

> It still seems passing strange to me that "preceding::c[1]" should give
> different results than "(preceding::c)[1],

ordering (and so [1]) are only defined in a step. but an Xpath
expression, including () expressions only return sets.
You may thave wanted (preceding::c) to return something in reverse doc
order, but what about
(preceding::c|following::c|id('ggg')|$x) here intuition is less helpful about any
natural order so the spec just specifies that the if you filter such an
expresion with a [] predicate then the current node list is produced by
sorting forwards document order. (Actually it cunningly hides this fact
by instead stating that the default axis is child:: but the _only_
effect of this default axis is to specifying the ordering)


This is all different (and less natural) in Xpath2 which is based on
sets rather than lists. Set union naturally does "the right thing" but
the natural operation on lists is concatenation which isn't usually
what's wanted, so to get the right behaviour Xpath2 drafts specify that
certain operations (ike / and |)  explictly sort and remove duplicates
to obtain a list in doc order. This works but is less natural to specify
as you have to specify this behaviour on each operation.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list