28041 2015-02-17 15:48:56 +0000 [XSLT30] Maps have implementation defined order, but this is not specified as such 2015-10-29 09:50:44 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Member-only Editors Drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.online mike abel.braaksma public-qt-comments oldest_to_newest 117988 0 abel.online 2015-02-17 15:48:56 +0000 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. 118163 1 mike 2015-02-25 21:23:23 +0000 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. 118180 2 abel.braaksma 2015-02-26 12:14:06 +0000 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?. 118703 3 mike 2015-03-20 10:00:25 +0000 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.