> Maybe I don't understand this right but I thought that
> 1) there is an order in a collection (within a snapshot)
> 2) this order extends to the document order for nodes that are descendants of
> different nodes in the collection.
> However, the nodes that are inserted into a collection are copied and thus
> have a new identify and the order in the collection does not have to be
> a) the document order of the source document or
> b) the insertion order.
> These tests take the nodes from fn:doc("auction.xml")//item, insert them into
> a collection and assume that the result of reading this collection is still in
> the document order found in auction.xml. I think that there is no reason why
> this order has to "survive" the insertion into and extraction from the
> collection.

I agree with all of the above, but my point was that an expression like:

let $x as element() := dml:collection($ns:coll_1)[1]

is perfectly valid and returns a stable result, even if the collection is 
unordered. It is true that the result may be different depending on the 
underlying store (i.e., the result is implementation-dependent), but this is 
not a reason to forbid such tests from our test suite.

I guess the reason for this change is that the sausalito store returns a 
different result, right? If so, a better solution is to add the sausalito 
result as an alternative expected result. I believe the testdriver has the 
ability to handle multiple expectected result, and that this is done via the 
.spec files, but I do not remember the details.
Your team Zorba Coders is subscribed to branch lp:zorba.

Mailing list: https://launchpad.net/~zorba-coders
Post to     : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help   : https://help.launchpad.net/ListHelp

Reply via email to