xsl:merge-source returning sequences of > 1 items

I wrote a grounding expression as an example in bug 29142, comment#3 for the xsl:merge-source/@select, which returns a sequence of more than one item. The example was:

select="/log/items ! (xs:dateTime(@ts), string(@error), string(@server))"

This then left me wondering about a few things:

1) we allow any sequence to be returned in both streaming and non-streaming scenarios, which is good, but what is the focus item in these scenario's inside xsl:merge-action?

2a) what happens when the result is unordered, for instance with select="let $n := log/item return copy-of(($n/time, $n/error))"? The input sequence may originally be in the right order, but using copy-of (or snapshot) makes its (relative) order stable, but implementation-defined.

2b) same as (2a), but for select="/log/items/@*". 

3) perhaps more importantly, what is the focus item for xsl:merge-key?

>From how it is written in the prose, I think the answer for (1) and (3) is "any one of the three items, in sequence order as written", which means that with such select statement, you are *not* selecting a sequence of three items for each iteration and as focus for xsl:merge-key (you cannot have the focus on three items at once). As such, it is probably quite meaningless, but a legal expression. A better example would be to use a map constructor here to keep the items together.

On (2a), I think that $n/time and $n/error remain in their relative positions, because they are an ordered sequence. On (2b) I think it just remains implementation defined and, depending on the input and the xsl:merge-key settings it may or may not raise unordered errors on a processor.

Cheers,
Abel

Received on Friday, 16 October 2015 10:52:49 UTC