[Bug 22298] Function fn:outermost should be allowed to work with free ranging expressions

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

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
The working group requested to see a more detailed example of the problem.
After a few tries and some help in the last telcon (July 11, 2013) I revisited
the following example in this mail
(https://lists.w3.org/Archives/Member/w3c-xsl-wg/2013Jul/0022.html):

<xsl:value-of select="outermost(.//table/caption)"/>

The analysis (copy from the mail, copied here for people without access to the
mail archives):

Analysis revisited (very detailed, to make sure I bring my thought
process across):

1. Determine the syntactic context (19.3.1).
1.1 outermost() is an "inherited context"
1.2 the inherited context is a pseudo context, look at the containing construct
1.3 the construct is the select-attribute of xsl:value-of 
1.4 this is a node-value context

2. Determine whether xsl:value-of is streamable
2.1 The rule under 19.3.4 states: look at General Rules for Streamability
2.2 The sweep requires to look whether the subsconstructs are consuming or
motionless
2.3 Here, the only subconstruct of xsl:value-of is the select-attribute

3. Determine whether the expression in the select-attribute is motionless or
(group-)consuming
3.1 Because of the inherited context, we must look at the inner expression
.//table/caption
3.2 The expression is a RelativePathExpr [35] under 19.3.7
3.3 Rewrite the expression as ./descendant-or-self::table/caption
3.4 The new rule (1) states we can ignore . and should look at the other
operands
3.5 We know from 1.4 above that this is a node value context, see rule (4)
3.6 Rule (4) requires to determine whether the expression is incrementally
consuming

4a. Determine whether the expression is incrementally consuming
4a.1 Under 19.3.8 we find that each step must be a child-selection expression
or a call to outermost()
4a.2 Currently, we look at descendant-or-self::table/caption
4a.3 This expression is not incrementally consuming

4b. Determine whether the expression is incrementally consuming
4b.1 We include outermost() in our expression analysis
4b.2 The expression to investigate under 19.3.8 is now
outermost(descendant-or-self::table/caption)
4b.3 Under (3) we find that we need to determine whether the argument of
outermost() is consuming

5. Determine whether .//table/caption is consuming (following 4b)
5.1 Rewrite to descendant-or-self::table/caption (see 3.3 and 3.4 above)
5.2 The context is unclear after step 4b.3
5.3 Assuming node value context, rule (4) brings us back to 4a or 4b

It turns out that, using this analysis, it is not possible to determine whether
outermost(expr) is streamable or not. The main problem manifests itself when
trying to determine whether the node value context is incrementally consuming,
which brings us into an eternal analysis loop.

Another hickup in the analysis is knowing when to look at the whole expression
(including outermost(), as in 4a vs 4b) or look at the expression of the first
argument. The way inherited context is described, it seems like you should look
at the inner expression, and not at outermost().

Note that, following the same logic, <xsl:value-of
select="innermost(.//table/caption)" /> isn't streamable either, yet for
another reason: 4b is not an applicable move, so 4a is the final rule that
determines that this expression is not streamable. In the case of the inherited
context for subsequence(), this is logical, because it could return overlapping
nodes. In the case of inner/outermost, this doesn't seem the way to go, because
overlapping nodes are not possible with these functions.

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

Received on Wednesday, 17 July 2013 19:33:02 UTC