Created attachment 1646 [details]
reduced test case

Thanks for raising this.

I think that

(a) the spec doesn't currently provide a clear answer to the question

(b) it's desirable that this test case should work, i.e that the parent merge key/merge group should be available except within the merge-action of the child

(c) in looking for analogies in xsl:for-each-group, I'm not sure the text is very clear there either.

Abel referred us to this text which provides an indication of the intent:

If neither of for-each-item and for-each-stream is present, the xsl:merge-source element defines a single merge input sequence. This sequence is the result of evaluating the expression in the select attribute. *This is evaluated using the dynamic context of the containing xsl:merge instruction.* This sequence will be merged with the sequences defined by other xsl:merge-source elements, if present.

The editor was actioned to come up with a proposal for clarification of the rules.

There seem to be a number of cases we have to consider.

(A) xsl:merge-source/@select when there is no @for-each-item or @for-each-stream. In this case we state "[The select expression] is evaluated using the dynamic context of the containing xsl:merge instruction. This is the case that applies to this example, and it makes it pretty clear that the example should work.

(B) xsl:merge-source/@for-each-item. Here we say:

(B1) The for-each-item expression is evaluated with the dynamic context of the containing xsl:merge instruction

(B2) the select attribute is evaluated with the focus for the evaluation as follows...

We don't explicitly say anything about other aspects of the dynamic context for the evaluation of the select attribute.

(C) xsl:merge-source/@for-each-stream. 

(C1) We don't say anything about the dynamic context for the evaluation of for-each-stream.

(C2) We say "These anchor items are then used in the same way as a sequence of anchor items selected directly using the for-each-item attribute." which hints that the dynamic context for the select expression follows the same rules as in the for-each-item case.

(D) xsl:merge-key/@select (or the contained sequence constructor): we say "This is evaluated with a singleton focus based on J, or, if streamable=yes is specified on the xsl:merge-source, a singleton focus based on a snapshot of J (see 15.4 Streamable Merging)." We say nothing about other aspects of the dynamic context.

(E) Attribute value templates on xsl:merge-key: we say "their effective values are evaluated using the focus of the containing xsl:merge instruction." We say nothing about other aspects of the dynamic context.

In 15.6 we have a non-normative note: "The current merge group and key are set during the evaluation of the sequence constructor contained in the xsl:merge-action element. They are initially absent, and they are cleared by all invocation constructs, which means in effect that the functions current-merge-group and current-merge-key can only usefully be invoked from instructions appearing lexically within the xsl:merge-action element." But this doesn't help us much because all these cases are lexically within the xsl:merge-action of the outer xsl:merge.

The statement that the current merge group and key are cleared by all invocation constructs appears normatively in 15.6.1 and 15.6.2.

Section 5.3, the general description of the static and dynamic context, sheds no additional light: for these components it delegates entirely to 15.6.

I think we should add the general rules (in 15.6): (part of this is transferred from 15.6.1 and 15.6.2).

<quote>
The current merge group and current merge key are available within the sequence constructor contained by an xsl:merge-action element. The values are initially absent during the evaluation of global variables and stylesheet parameters, during the evaluation of the use attribute or contained sequence constructor of xsl:key, and during the evaluation of the initial-value attribute of xsl:accumulator and the select attribute of contained sequence constructor of xsl:accumulator-rule. All invocation constructs set the current merge group and current merge key to absent. 

Note: Taken together, these rules mean that any invocation of current-merge-group or current-merge-key that is not lexically scoped by an xsl:merge-action element will raise a dynamic error.

When an inner xsl:merge instruction is lexically nested within the xsl:merge-action element of an outer xsl:merge instruction, any use of current-merge-group or current-merge-key that appears within the xsl:merge-action of the inner xsl:merge instruction is a reference to the current merge group or key of the inner xsl:merge instruction, while any such reference that appears within the outer xsl:merge-action element, but not within the inner xsl:merge-action, is a reference to the current merge group or key of the outer xsl:merge instruction. This means, for example, that a reference to the current merge group of the outer xsl:merge can appear in the select attribute of an xsl:merge-source child of the inner xsl:merge.
</quote>

Additional changes: 

In 15.3, after "When the for-each-stream attribute is present, its value must be an expression that returns a sequence of URIs." add "The expression is evaluated with the dynamic context of the containing xsl:merge instruction." After "These anchor items are then used in the same way as a sequence of anchor items selected directly using the for-each-item attribute." add: "in particular, the focus for the select expression is established in the same way.

Test case added - merge-089

I have updated the spec as proposed in comment #4.

The change was accepted.