We discussed this in the face to face meeting in Prague.

The syntax of merge-source does need to be revamped in the light of the current handling of streaming and streamability analysis.

We concluded that we will need three mutually exclusive attributes for merge-source:

- one to accept an expression which returns a set of objects (which are not necessarily streamable), each of which provides an input to the merge

- one to accept an AVT which evaluates to a sequence of URIs, each of which provides a document node as input to the merge

- one to accept an AVT which evaluates to a single collection URI, where the member documents of that collection are inputs to the merge

The second and third attributes can be regarded as opening the documents with doc() or document() in the normal case, and as opening streams analogous to those opened with the xsl:stream instruction when the merge-source element bears the attribute value specification streamable="yes".

We seem to have consensus this far, but no useful consensus on the names of these attributes.

Rather than the proposed three attributes, I propose we make it two:

for-each-item  

which is an expression that selects the anchor items (equivalent to the present for-each)

for-each-stream

which is an expression that selects a sequence of URIs, each being the URI of a streamed input document. Typical usages:

for-each-stream="'a.xml'"

for-each-stream="('a.xml', 'b.xml')"

for-each-stream="uri-collection('collection-uri')"

Do we also need validation and type attributes to allow control over input validation?

The WG considered the proposal in comment 2 and found it good.  The answer to the question at the end of comment 2 is "yes":  we believe having type and validation attributes on merge-source would be a good things.

The rules for guaranteed streamability must still be formulated, and the references to the doc(), document(), and collection() functions must be removed, to make the description logically consistent.

Fixed as agreed.

I'm taking the liberty of reopening this because of some (possible) bugs introduced in the new streaming rules (numbered 1 to 6):

1) About rule #2
"The expression in the select attribute of that xsl:merge-source element must have striding posture;"

This should probably be:

"The expression in the select attribute of that xsl:merge-source element must have striding or grounded posture and a sweep that is not free-ranging;"

I think the limitation on only the posture is not necessarily enough, yet I seem to fail to find an expression that is free-ranging and striding/grounded at the same time. I.e., the expression snapshot(a//b) is roaming and free-ranging because the argument has usages absorption, though at first look it might seem like grounded and free-ranging (because of the result of snapshot always being grounded).

2) About rule #4
"The select expression of each merge key in that xsl:merge-source element must be a motionless expression;"

This should be something like:

"The select expression of each merge key in that xsl:merge-source element must be a motionless expression, assessed with the posture of the select expression of the immediate xsl:merge-source parent;"

3) About rule #5
Typo: "and and either" => "and either a"

Also, the context item of xsl:merge-action is the result of the select expression of xsl:merge-source, hence it might make sense to set the context posture to the higher result posture of all select expressions (allowing that, if all are grounded, free-ranging expressions are allowed). However, this might over-complicate things. If we don't add this, we should perhaps explain what the context posture is for the assessment of the posture of the xsl:merge-action (striding?).

4) About the example
Currently, the example is not streamable with the rules given. It is streamable if the changes mentioned above are applied.

The Note on the example should probably go into the green section of the example, as it applies to example, not to the body of the text of section 15.4.

5) About context posture
It is not clear from the get-go what the context posture is for assessing the select expression of the xsl:merge-source element. Perhaps it is irrelevant?

6) About 19.8.4.25, Streamability of xsl:merge
There is no rule about how to assess xsl:merge-source children, the operands are not known. 

The current rule:
"If all xsl:merge-source children are motionless then the instruction is grounded and motionless."

does not take into account a that a select expression on xsl:merge-source can be motionless, but can still select streamable nodes, hence allowing the xsl:merge-action to return streamable nodes and still be motionless. This should be disallowed.


I think we could fix this by writing something like the following:

#1. If all xsl:merge-source without @for-each-stream and @for-each-item have a select expression that is motionless and grounded;

#2. If all xsl:merge-source with @for-each-item have a for-each-item expression that is grounded and motionless;

#3. If all xsl:merge-source with @for-each-stream follow the rules under 15.4 Streamable Merging;

Then grounded and motionless. Otherwise, roaming and free-ranging.

It appears that MK and I were having the exact same thoughts regarding streamability of xsl:merge, item (6) in the list in the previous comment 5 was tackled as part of bug 24497.

I think the remaining issues are subsumed by the discussion of streamed merging in bug #25335: marking this as a duplicate for convenience.

*** This bug has been marked as a duplicate of bug 25335 ***