[Bug 28833] [XSLT30] Streamability of fn:current and varrefs should be roaming in higher-order operands

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

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> Is it sufficient to say that current() and references to streaming 
> parameters are roaming and free-ranging if used within a higher order 
> operand of a construct whose focus-setting container is not grounded?

No, unfortunately not, consider a/copy-of(b)/current()/c with CP striding. The
focus for the third segment can be a streaming node, but the expression was
already consuming and moved on, so current()/c can no longer be evaluated.

I think that the main issue is with path and simple map expressions, where the
StepExpr is not an AxisStep. I propose to solve this by adding rules for
StepExpr as follows:

19.8.8.x Streamability of StepExpr

1) if the StepExpr is an AxisStep, the posture and sweep of the axis step, see
19.8.8.8.
2) if the StepExpr is a PostfixExpr E, the GSR applies, where the (fictive)
operand is a higher-order operand (HOO) with usage transmission and the context
posture is the posture of E.

With this rule added, the expression a/copy-of(b)/current()/c (assuming context
posture Striding) is now assessed as follows:

1) it is a path expression, assess a/copy-of(b) first
2) result: consuming and grounded
3) assess (cons, gnd)/current()
4) the new rule says apply GSR for E with as HOO
5) E is current(), which is motionless and striding
6) apply GSR for motionless, striding with usage T
7) according to GSR this is potentially consuming
8) according to GSR 2.d.i (HOO rule) it is roaming and free-ranging

For the Simple Mapping Expressions, since the production exists of PathExpr,
they will automatically come to the rules above, so nothing more to do there.

For Filter Expressions, these can only end up in being in HOO position inside
the filter, which must be motionless, so there is no problem if fn:current is
used inside the predicate as long as it is not consuming. If the P-part of the
filter expression is a path expression, the new rules above kick in. Nothing to
do there.

For variable references, they will now get to the GSR if part of a
SimpleMapExpr or PathExpr and rule 2.d.i will prevent their usage in HOO
positions.

For inline function declarations, I can't find it back in XP30, but I believe
that the context item expression is disallowed inside it (unless bound to a
variable), so I think the fn:current() function should be disallowed as well
(similarly to it being disallowed in a stylesheet function). If it is bound to
a variable, this is already disallowed, so it cannot happen.

For xsl:for-each-group, the GSR applies and the patterns are already considered
higher-order operands, nothing to do there.

> There seem to be sufficiently many that a general statement is needed

We already have a general statement on higher-order operands and what they are.
But we might expand on it and/or add some Notes or examples.

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

Received on Saturday, 27 June 2015 15:38:48 UTC