> 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) 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. -- https://code.launchpad.net/~zorba-coders/zorba/unordered-collection-tests/+merge/101374 Your team Zorba Coders is subscribed to branch lp:zorba. -- Mailing list: https://launchpad.net/~zorba-coders Post to : firstname.lastname@example.org Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp