This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This bug originated by XSLWG mail: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Apr/0063.html (member only). This bug was discussed and confirmed by the XSLWG telcon of 2015-06-04, see minutes: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Jun/0011.html (member only). The spec does not say what the focus is for the select attribute or the sequence constructor of xsl:merge-key. It should (probably) be set to the context item set by the select attribute of xsl:merge-source. Suggestion from the aforementioned mail is: "We should probably do something similar as has been done for xsl:merge-action, where we clearly define the context item, position and size."
I propose to define the evaluation of merge keys as follows: <p diff="add" at="S-bug28762">The value of <var>N</var>th merge key value of an item <var>J</var> in a <termref def="dt-merge-input-sequence">merge input sequence</termref> <var>S</var> is the result of the expression in the <code>select</code> attribute of the <var>N</var>th <elcode>xsl:merge-key</elcode> child of the corresponding <elcode>xsl:merge-source</elcode> element, or in the absence of the <code>select</code> attribute, the result of the contained <termref def="dt-sequence-constructor"/>, evaluated with a <termref def="dt-focus"/> in which the <termref def="dt-context-item"/> is <var>J</var>, the <termref def="dt-context-position"/> is the position of <var>J</var> within <var>S</var>, and the <termref def="dt-context-size"/> is the number of items in <var>S</var>.</p> However, for this to work we need to change the definition of "merge input sequence" to be (in the case where sort-before-merge="yes") the sequence prior to sorting, rather than, as currently, the sequence after sorting. This appears to work.
Thinking about this again... I chose those rules to be consistent with the rules for xsl:sort keys. But sorting assumes you have the whole sequence available, while merging is all designed for streamability. So I don't think allowing use of position() and last() (in relation to the full input sequence) make much sense. I propose instead to use a singleton focus based on the individual item.
I have applied the solution that uses a singleton focus, but leaving the bug open for WG review. Note also that when streaming, the context item for evaluating the key is the snapshot node, not the original (we already say this).
The WG approved the proposed solution on 18 Jun 2015.
The change has been applied to the specification.