30382 2018-12-20 19:18:29 +0000 [XSLT30] xsl:merge-key is defined in terms of xsl:sort, this leads to conflicting results when neither select or sequence constructor are present 2019-02-18 16:06:51 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC Windows NT NEW P2 major --- 1 abel.online mike public-qt-comments oldest_to_newest 129459 0 abel.online 2018-12-20 19:18:29 +0000 Currently xsl:merge-key is defined mostly in terms of xsl:sort and refers to that section, specifically, section 15.5 says: "The syntax and semantics of an xsl:merge-key element are closely based on the rules for the xsl:sort element (the only exception being the absence of the stable attribute)" However, xsl:sort defines the absence of both the sequence constructor and the select attribute to be treated as select=".". In contrast, the text on xsl:merge-key says: "[...] the result of the expression in the select attribute of the Nth xsl:merge-key child of the corresponding xsl:merge-source element, or in the absence of the select attribute, the result of the contained sequence constructor." Further paragraphs don't specify this, which means that an empty xsl:merge-key returns the empty-sequence(), and not the context item. This leads to two possible ways of interpretation of the text: (1) Merge by the rules of xsl:sort, meaning the context item is selected (2) Merge using the empty-sequence(), which results in declaration-order sorting (by virtue of the stability conflict resolution rules) I think the second option is not what was intended as it seems a very uncommon use case. But it is easy to go either way with the current rules. Since it is not uncommon for instructions to have a default for the absence of the select attribute and users are accustomed to that behavior, I think we should fix this omission by choosing option (1) above in an erratum. I have not researched (yet) how it is presently implemented in existing processors. 129497 1 mike 2019-02-13 15:07:52 +0000 I think that the intent, given the way the rules are written, is to delegate the specification to xsl:sort except where otherwise specified. Therefore I think that where there is no select attribute and an empty sequence constructor, select="." should be assumed. I am drafting erratum E42 on that basis. 129510 2 mike 2019-02-18 16:06:51 +0000 Note there is an overlap here with changes previously agreed by the WG in bug #30130.