30377 2018-12-17 20:43:54 +0000 [XSLT30] Merge keys with NaN and empty-sequence() cause non-deterministic behavior 2019-02-20 09:51:25 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC Windows NT NEW P2 normal --- 1 abel.online mike public-qt-comments oldest_to_newest 129451 0 abel.online 2018-12-17 20:43:54 +0000 We define the process of sorting merge input in reference to the xsl:sort process, which defines NaN to be equal to itself and empty-sequence() to be equal to itself, but preceding any other item. This works fine for sorting, but in the text of how a merge-group is formed, we define that in terms of the 'eq' operator (section 15.7): "Generally, two sets of merge key values are distinct if any corresponding items in the two sets of values do not compare equal under the rules for the XPath eq operator..." But under the eq operator, NaN is not equal to itself and comparing anything to the empty-sequence yields the empty sequence. Therefore, under the current rules, one NaN is distinct from another NaN in a merge-group (and therefore wouldn't end up in the same group), but not when sorting. This is problematic, since the current-merge-group should be equal to what is considered equal during the sorting process. I think the intent of the text is clear (empty-sequence() is grouped together, and so is NaN), but I'd propose to add a clarification for these edge cases (or refer back to the sorting process, something like: what is equal during sorting ends up in the same bucket). 129498 1 mike 2019-02-13 15:51:49 +0000 I think we should resolve this by delegating more strongly to the xsl:sort rules, especially §13.1.2 129542 2 abel.online 2019-02-20 09:51:25 +0000 A proposed erratum E39 has been drafted and was published on 13 Feb 2019, HTML version: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E39 I would like to discuss the erratum, it seems to cover and fix my concern but I'm unsure if it covers the full range of cases, perhaps because we use negation (do not compare equal under the 'eq' operator). The stronger reference to the xsl:sort section definitely helps.