Re: xsl:merge-source returning sequences of > 1 items

(ACTION 2015-10-22-001: Mike Kay to respond to this message…)

1. The context item within xsl:merge-action is well defined, but not very useful. The merge group is the set of items from all the input sequences that share a common merge key, and the context item is the first item in the merge group. Most commonly you will use current-merge-group() to access the whole group.

2. All sequences are ordered, but in some cases the order is implementation-defined or -dependent. If the order is implementation-defined or -dependent then an error MAY occur due to the sequence not being in merge-key order.

3. The context item for xsl:merge-key is well-defined in the spec, it is the item whose merge key is being computed. See the text just below ERR XTSE3200. In the most recent draft I moved this paragraph to a more logical place, but it is not new.

Michael Kay
Saxonica


> On 16 Oct 2015, at 11:52, Abel Braaksma <abel.braaksma@xs4all.nl> wrote:
> 
> 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 Thursday, 29 October 2015 21:53:25 UTC