This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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).
I think we should resolve this by delegating more strongly to the xsl:sort rules, especially ยง13.1.2
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.