Code review comment for lp:~zorba-coders/zorba/unordered-collection-tests

> 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.