This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Under map:keys we say that the order of the result is implementation defined. Under maps (section 21.1 and 21.1.1) we do not say such a thing. Furthermore, we do not clarify whether deep-equal(map:keys($m), map:keys($m)) is pairwise equal or not, but we do say that map:keys is deterministic (and the definition of deterministic in XP30 is defined that it must be pairwise equal). The function map:for-each-entry has the same ambiguity. This bug equally applies to XSLT 3.0 LCWD and XPFO 3.1 CR.
It's not correct to suggest that 21.1 says nothing. It defines a map as "A map consists of a set of entries. " Defining it as a set makes it clear that in the data model, there is no intrinsic order. The problem only arises with functions that have to presen the set as a sequence, namely map:keys() and map:for-each-entry(). It's also clear for both these functions that the result order is implementation-dependent (NB, not implementation-defined). So the only remaining question is whether, when the results of a function are implementation-dependent but deterministic, two calls with the same arguments are required to deliver the same result. F+O answers this question in 1.6.4: <quote> Some functions (such as fn:distinct-values and fn:unordered) produce results in an ·implementation-defined· or ·implementation-dependent· order. In such cases there is no guarantee that the order of results from different calls will be the same. These functions are said to be non-deterministic with respect to ordering. </quote> That seems clear enough to me.
It wasn't immediately obvious to me that the term set had that meaning, but it makes sense now. The section in F&O you refer to starts with "All functions defined in this specification are ·deterministic· unless otherwise stated. Exceptions include the following:". But if we look up the said functions (fn:unordered), it is deemed deterministic and there is no notion that it is non-deterministic in regards to ordering. I am unsure whether this is a closed set of functions or not and whether it applies to extension functions like the ones we define in XSLT. Does it perhaps make sense to add a line something like "this function is non-deterministic with respect to ordering" and/or refer to that section in F&O?.
The WG resolved to fix this by adding, in the specifications of map:keys and map:for-each, a reference to the definition of functions that are "non-deterministic with respect to order" in F+O. This reference has been added to both the XSLT 3.0 and XPath 3.1 versions of the specifications.