[Bug 27250] [XSLT30] xsl:number applies general streamability rules to a pattern with usage inspection


--- Comment #3 from Michael Kay <mike@saxonica.com> ---
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 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]"/>

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

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

You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 9 January 2015 19:50:24 UTC