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 27250 - [XSLT30] xsl:number applies general streamability rules to a pattern with usage inspection
Summary: [XSLT30] xsl:number applies general streamability rules to a pattern with usa...
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: P2 normal
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: 2014-11-05 14:40 UTC by Abel Braaksma
Modified: 2015-10-29 09:50 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2014-11-05 14:40:47 UTC
Under 19.8.4.30 Streamability of xsl:number, item 4, we say:

<quote>
4. The from and count patterns if present; these are higher-order operands with usage inspection.
</quote>

But we do not have a notion of patterns in the context of higher order operands, or in the context of inspection. We just have "classifying patterns" that are either motionless or free-ranging.

A solution could be to say instead:

<proposal>
4. The from and count patterns, if present, must be motionless patterns, as defined under 19.8.9 Classifying Patterns.
</proposal>
Comment 1 Michael Kay 2014-11-13 18:00:20 UTC
Noted that for-each-group has the same issue with its operand patterns, it uses a similar form of words (The group-starting-with or group-ending-with patterns if present; these are higher-order operands with usage inspection._
Comment 2 Michael Kay 2015-01-07 23:46:14 UTC
Proposed solution:

(I) For xsl:number, the rules become:

If either of the from or count patterns is present and is not a motionless pattern, then the xsl:number instruction is roaming and free-ranging.

Otherwise, the posture and sweep of xsl:number follow the general streamability rules. The operand roles and their usages are as follows:

1. The value attribute if present (usage absorption)

2. The select attribute if present (usage navigation)

3. The attribute value templates in the format, lang, letter-value, ordinal, start-at, grouping-separator, and grouping-size attributes (usage absorption)

(II) For xsl:for-each-group:

* delete rule 1(f)

* Add after rule 1:

1½. If either of the group-starting-with or group-ending-with patterns is present and is not a motionless pattern, then the xsl:for-each-group instruction is roaming and free-ranging.

(I'm wondering if rule 1 can be simplified further. If the select expression is grounded, then surely it doesn't matter what the group-by or group-adjacent expressions are? If we can get rid of constraints on group-starting-with, why not on group-by? But it's late at night, I'm not 100% confident of that).

(III) In 19.8.9, Classifying patterns, under the introduction

"A pattern is motionless if and only if it satisfies all the following conditions:..."

add a third condition:

* The pattern does not contain a variable reference that is bound to the streaming argument of a stylesheet function declared with streamable="yes".

Note: this last condition can occur only in the pattern-valued attributes of instructions such as xsl:for-each-group and xsl:number when used within a streamable stylesheet function.
Comment 3 Michael Kay 2015-01-09 19:50:22 UTC
The WG asked me to explore the alternative solution, of making the GSR work properly when patterns are supplied as operands. I think this is actually less disruptive than I feared.

Firstly, let's see what the GSR needs to know about an operand.

(a) The static type
(b) The sweep and posture
(c) The operand usage
(d) Whether or not the operand is higher-order.

(a) and (b) are properties of the actual operand itself; (c) and (d) are properties of the operand's role within its parent expression.

For the from and count patterns within xsl:number, the sweep and posture are properties of the pattern defined in 19.8.9 Classifying Patterns; and (c) and (d) are given in 19.8.4.30 in the streamability rules for xsl:number. The only thing missing is (a), the type of the pattern, and we can deem all patterns to have a type of "boolean", on the grounds that evaluating a pattern against any node gives a yes-or-no answer. (In fact the static type T is not used when usage is inspection, but we might as well define it anyway).

With this proviso, I think the current rules (almost) work. 

The first two operands are given as:

The value attribute if present (usage absorption)
The select attribute if present (usage navigation)

which should change, I think, to:

1. If the value attribute is present, then the expression in the value attribute (usage absorption). Otherwise, the expression in the select attribute (defaulting to ".") (usage navigation).

For example consider

<xsl:number level="any" from="section"/>

We have two attributes, select="." (navigation) and from="section" (inspection). The first operand is enough to make the expression free-ranging; the pattern is motionless so it doesn't affect the outcome.

To find an example where it does matter, consider

<xsl:function name="f" streamable="yes">
  <xsl:param name="n" as="node()"/>
  <xsl:number select="$global//x" from="section[@nr=$n]"/>
</xsl:function>

Here the select attribute $global//x is grounded and motionless, so everything depends on the pattern. If we accept my proposed change (III) above, then the pattern is not motionless, because it contains a reference to the streaming argument of a streamable stylesheet function; it is therefore roaming and free-ranging, and the xsl:number instruction is therefore roaming and free-ranging. But if the instruction were changed to

<xsl:number select="$global//x" from="section"/>

then the pattern, and hence the xsl:number instruction, would become motionless.

Describing the pattern operand as a higher-order operand is not wrong, but unnecessary, because the only time being higher-order makes any difference is when an operand is consuming, and patterns are never consuming. Equally, describing the operand usage as inspection is unnecessary (but not wrong), because the posture of a pattern must be either grounded or roaming, and the usage of an operand makes no difference when the posture is grounded or when it is roaming.

Conclusions: we can make this work by

(a) specifying for the sake of completeness that the static type of a pattern is boolean

(b) explaining in the streamability rules that the pattern operands are classified as (higher0rder, inspection) only for completeness and that this makes no difference because the GSRs do not use these properties

(c) adding the proposed rule (III) for the conditions under which patterns are motionless.
Comment 4 Michael Kay 2015-01-15 22:25:38 UTC
The proposal in comment #3 was accepted.