>
> From what I can see in the XQuery/XPath WDs, it doesn't look as though
> there will be a concept of 'sets' in XPath 2.0. My guess is that a
> location path will return a sequence in document order.

That's correct. There won't be any sets; there will just be some functions
and operators that treat sequences as if they were sets. This is on the
principle that the set of "sequences of distinct nodes in document order"
has a one-to-one correspondence with the set of "sets of nodes", therefore
the concept of a node-set can be modelled as a sequence of distinct nodes in
document order. You potentially lose some type-checking and polymorphism (as
Dimitre pointed out), but it's actually a useful simplification to have only
one kind of collection.

> I haven't noticed anything where, when manipulating node sequences in
> the same way as you currently construct node sets, things work
> differently from the way they would if you were actually working with
> node sets.

Correct. This should be 100% compatible. I'll talk to you off-the-record
some time about the debates that produced that outcome...
>
> As written, xf:identity-distinct() converts a node sequence containing
> duplicates to one that doesn't, but to get something that works in the
> same way as a node set, you'd have to union the sequence with itself
> (as above) or use xf:sort() (though I don't think that should be a
> function in any case).
>
> The other relevant function is xf:unordered(), which acts as a 'hint'
> to the processor that the sequence can be treated as unordered. I
> don't really understand when you'd use that, though, I must admit.

You can expect changes in these functions in the next working draft. (The
published data model itself is now very stable, with the possible exception
of modelling and naming of complex types.)

Mike Kay


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