28762 2015-06-04 19:45:25 +0000 [XSLT30] Focus of xsl:merge-key's select attribute and sequence constructor 2015-08-17 08:41:32 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 120716 0 abel.braaksma 2015-06-04 19:45:25 +0000 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." 120723 1 mike 2015-06-05 10:40:38 +0000 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. 120724 2 mike 2015-06-05 12:44:46 +0000 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. 120727 3 mike 2015-06-05 13:31:32 +0000 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). 121551 4 mike 2015-07-01 19:51:35 +0000 The WG approved the proposed solution on 18 Jun 2015. 122632 5 mike 2015-08-17 08:41:32 +0000 The change has been applied to the specification.