This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30379 - [XSLT30] Anchor item is missing from "Terminology of merging" and lacks a definition
Summary: [XSLT30] Anchor item is missing from "Terminology of merging" and lacks a def...
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-19 13:08 UTC by Abel Braaksma
Modified: 2018-12-20 12:21 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2018-12-19 13:08:27 UTC
The term "Anchor item" is used in several places, under the merging section it appears in bold (suggesting a definition) and in italics (when it is actually defined).

I think the layout may have gotten mixed up here, where the actual definition was perhaps intended to be moved to the section "Terminology of merging" (that seems the logical place for this).

Since the term is key in understanding merging, I suggest we provide this (purely editorial) change through an upcoming erratum, specifically:

* move the term as a descriptive definition to the "Terminology of merging" section
* refer to this definition from the locations in the text where it is used
* fix the current layout (italian, bold) where appropriate
Comment 1 Abel Braaksma 2018-12-19 17:29:30 UTC
In line of the bug report below, I think that the term "anchor items" is used incorrectly in the following paragraph (under 15.3):

"The number of anchor items selected by an xsl:merge-source element, and therefore the number of input sequences, is variable, but the input sequences selected by one xsl:merge-source element must all use the same expressions to select the items in the input sequence and to compute their merge keys. If different expressions are needed for different input sequences, then multiple xsl:merge-source elements can be used. "


The way I understand it is:

* for-each-item, for-each-source each can select a sequence of anchor items (seq of items or seq of documents)
* for each item in this sequence, the @select expression creates a merge item (the resulting sequence is the merge input sequence)
* in absence of these attributes, the anchor item doesn't exist (or can be considered the context), and the select expression returns the merge input sequence
* the result of xsl:merge-source is therefore a merge input sequence, and not a sequence of anchor items

I think the above statement conflicts with that:

* One xsl:merge-source element defines one (merge) input sequence, not multiple
* An xsl:merge-source element does result in anchor items, but in a merge input sequence and their corresponding keys

Perhaps we can clarify this by writing instead something like the following:

"The number of anchor items selected by the for-each-source or for-each-item expression is variable, but the merge input sequences selected by the select attribute all use the same expression  for each source item or document, and therefore to compute their merge keys. If different expressions are needed for different sequences of anchor items, then multiple xsl:merge-source elements can be used, with each a different expression in the select attribute."

We could add to this:

"Note however even though the resulting merge input sequences can differ in type, but that the sequence type of the corresponding xsl:merge-key select expressions should be the same, see [link to xsl:merge-key]."
Comment 2 Abel Braaksma 2018-12-20 12:21:28 UTC
Please scratch the previous comment. It is incorrect, specifically with respect to this sentence:

> One xsl:merge-source element defines one (merge) input sequence, not multiple

I've read several times over the section and the mentioned sentence and (still) find it quite hard to understand, but perhaps we can somehow clarify that.

* There are zero-or-more anchor items with for-each-source, for-each-item, there's one anchor item in their absence
* Each anchor item maps to one merge input sequence, which is specified by expr in the select attribute
* The keys are calculated with each item from the merge input sequence as singleton focus, and its size set to the size of the merge input sequence from the previous step
* Sorting and merging is done on these keys, the items in the output sequence (accessible through fn:current-merge-group) are those from the input sequence
* Keys are shared between all merge input sequences

Perhaps this is a better way of writing the mentioned sentence from comment#1?

"The number of anchor items selected by either for-each-source or for-each-item each defines a single merge input sequence through the select attribute. Therefore the total number of merge input sequences is variable (the total equals the total of anchor items), but the merge input sequences selected by one xsl:merge-source element must all use the same *** expression *** to specify the items to be selected for the merge input sequence. 

In addition, the expressions used to compute their merge keys are the same for each such merge input sequence. If different expressions are needed to specify the merge input sequence from the anchor items, or different expressions are needed to create the merge keys, then multiple xsl:merge-source elements can be used."

The last sentence from the previous post is still beneficial, I think (edited):

"Even though the merge input sequences can differ in type, the sequence types of the corresponding xsl:merge-key select expressions must be coercible to each other according to the function conversion rules, see [link to xsl:merge-key]."