[Bug 22933] [XSLT 3.0] Streamability rules: Simple Mapping Expressions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22933

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
"Should be possible" - indeed.

There is also a clear relationship to the rules for RelativePathExpr. This
gives us an opportunity to examine why the rules for xsl:for-each and for
RelativePathExpr are different. Let's look at the cases in turn.

1. For path expressions, we have the rule:

If either operand is a ContextItemExpr or a ForwardStep using the self axis,
followed in either case by zero or more motionless predicates, then the sweep
of the other operand;

which has no equivalent for xsl:for-each. It's very unlikely to arise with
xsl:for-each, but does that mean we should leave it out? It certainly needs to
be there for "!".

2. For RelativePathExpr we have the rule

If the first operand is motionless, then motionless;

For xsl:for-each the corresponding rule has additional qualifications: the
first relates to xsl:sort, which is a reasonable difference, and the second
relates to the use of group binding variables. This qualification is also
relevant to path expressions. However, I think it can be simplified.

I think there's another bug here. Consider the expression (1 to 10)/current().
The first operand is motionless so we deem the expression as a whole
motionless, regardless of the fact that current() is free-ranging. The issue
here is that there are a small number of constructs, including current(),
current-group(), and references to group binding variables, that can appear on
the rhs of "/" (or in the body of xsl:for-each) and depend on the "outer
context" rather than the "inner context" of the expression.

So I think this rule for RelativePathExpr needs to disallow references to
grouping variables and to current() on the rhs.

3. Under RelativePathExpr rule 3, we have:

If the syntactic context is an inspection context and the RelativePathExpr
takes the form of a RelativePathExprP that itself conforms to the rules for a
motionless pattern (see 19.3.10 Classifying Patterns), then consuming;

Clearly there's no direct equivalent for xsl:for-each because an xsl:for-each
instruction cannot take the form of a pattern. It's an odd rule though,
especially as the example given - exists(descendant::section) - isn't even a
RelativePathExpr according to the way we defined it. Somehow one feels this
rule shouldn't be necessary; it should fall out from the other rules.

4. Under xsl:for-each rule 3, we recognize group-consuming constructs of the
form 

<xsl:for-each select="$current-group"><xsl:value-of
select="child"/></xsl:for-each>

We don't have any corresponding rule to recognize $current-group/string(child)
as group-consuming; I can't see any good reason not to.

5. Rule 4 of RelativePathExpr and Rule 4 of xsl:for-each have similar effect
but they are phrased differently and are not in fact equivalent. For example,
the xsl:for-each rule recognizes 

<xsl:for-each select="a/b/c"><xsl:sequence select="name()"/></xsl:for-each>

but the RelativePathExpr rule does not allow a/b/c/name(). I think these two
rules should be aligned.

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

Received on Tuesday, 13 August 2013 10:01:43 UTC