This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I tried to find a definitive statement of how sorting works with xsl:merge-source, but failed to find it. The closest I got was in 15.5 about keys: "If the attribute sort-before-merge has the value yes, the input sequences will be sorted into the correct sequence before the merge operation takes place" Here "sequence" should probably be replaced by "order" (correct order). I doubt anybody will dispute that "correct order" here means anything else "sorted such that the merge operation doesn't raise XTDE2220", but we don't say this clearly. A similar statement is in 15.3: "If the attribute is present with the value yes, then each input sequence will first be sorted to ensure that it is in the correct order." I think it would be beneficial if we somehow link "correct order" to xsl:perform-sort, or xsl:sort and more importantly, make clear that the sorting process uses the merge-keys defined for xsl:merge-source, and as input takes the result of the xsl:merge-source/@select (that is, the merge input sequence, *not* the anchor items). Furthermore, we refer several times to the "input sequence", meaning the "merge input sequence", and we reference that term both meaning before and after sorting. However, the definition of "input sequence" itself explicitly states that the sequence is already sorted. Not sure how to cleanly fix this though (perhaps expand the definition, and also to hyperlink each mention of "input sequence" to the definition and/or renaming it "merge input sequence").
> However, the definition of "input sequence" itself explicitly states that > the sequence is already sorted. It appears to me that this ambiguity may have been introduced through the resolution of bug #28762 which updated the definition of "merge input sequence" to be defined as "before sorting". But some parts of the text still uses the term in either meaning.
In addition to the original report, I'm wondering whether sorting would work like xsl:sort, which has access to the size of the input, or like keys are evaluated when no sorting takes place, that is, with singleton focus. I'd be inclined to say that the text suggests that sorting "works like" xsl:sort, but that the singleton focus remains in place for sort-before-merge, just like with merging.