This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In Section 15.3, and the second paragraph we observe 'if the select attribute is omitted, the default value is ., which selects the context item'. There is a potential problem here if the merge instruction, say is written in an xsl:function, which has no context item passed in, then the xsl:merge-source context item will be undefined. For example, in the following function 's:merge1' we have an xsl:merge instruction which has a xsl:merge-source, with the select attribute omitted. For the xsl:merge-key the value of the select is ., this will error as xsl:merge-source does not have a valid context item: ... <xsl:function name="s:merge1"> <xsl:merge> <xsl:merge-source> <xsl:merge-input> <xsl:perform-sort select="doc('europe.xml')/europe/country"> <xsl:sort select="." order="ascending"/> </xsl:perform-sort> <xsl:merge-key select="."/> </xsl:merge-input> </xsl:merge-source> <xsl:merge-action> <out> <xsl:value-of select="."/> </out> </xsl:merge-action> </xsl:merge> </xsl:function> ...
I took an action at the Prague F2F to propose a solution to this one. It's surprisingly difficult, and I think the reason is that the merge-source/merge-input syntax and semantics are pretty dense. Having the two "select" attributes in a one-to-one relationship with each other is particularly confusing. I think we could do better if we refactored it. I would like to propose collapsing xsl:merge-source and xsl:merge-input into a single element with the syntax <xsl:merge-input name = qname for-each = expression select = expression > If for-each is present then the merge-input selects multiple input sequences, one for each anchor item selected by the for-each expression, which is used as the context item for evaluating the select expression. If for-each is absent then the merge-input selects a single input sequence, obtained by evaluating the select expression, which is then evaluated using the context of the merge-input instruction itself. The select expression can be replaced by a contained sequence constructor; the for-each expression can't. I think this will make it much clearer what's going on.
After considering various alternatives the WG began to find the proposal in comment #1 attractive and gave the editor an action to propose detailed text.
The WG reviewed the text in the editor's draft of the specification and approved it. Note that the sequence constructor option of the xsl:merge-source element has now disappeared; the main use case for it was to contain an xsl:perform-sort instruction, and the need for this has been removed by adding the attribute sort-before-merge="yes|no" with the default "no".