Bug #5067
closed
Stability of collection ordering
0%
Description
The spec says that by default collections are stable, so processing the same collection twice should give the same result.
It also says that a collection is a sequence (not a set).
This is difficult to reconcile with Saxon's use of multi-threading to process the items in a collection, which makes the order of processing unpredictable. Perhaps we should be doing multi-threading within the same constraints as xsl:for-each with a threads attribute, where the results are delivered in the original order.
Problem arose from consideration of test case cbcl-collection-002 where in Saxon-CS we are delivering the (integer) contents of the collection in an arbitrary order.
Updated by Michael Kay 2 months ago
- Status changed from New to Closed
I'm pushing for 4.0 syntax to support nondeterminism in collections (and elsewhere) as it's very costly to keep a copy of the collection in memory just in case the same collection URI is used more than once.
Meanwhile there's a deliberate non-conformance in the Saxon implementation, whereby collection() is nondeterministic by default. Given that decision, I don't think it's surprising that we should be failing this test, and I propose to live with it: the software is working as designed, even if it's not conformant.
For now I'm going to close the bug.
Please register to edit this issue
.