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 24528 - Streamability of xsl:number and from and count patterns
Summary: Streamability of xsl:number and from and count patterns
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-02-05 20:14 UTC by Abel Braaksma
Modified: 2014-06-05 18:11 UTC (History)
1 user (show)

See Also:


Attachments

Description Abel Braaksma 2014-02-05 20:14:38 UTC
Under 19.8.4.29 Streamability of xsl:number (http://www.w3.org/TR/xslt-30/#streamability-xsl-number), the fourth numbered item in the list says:

"The from and count patterns if present; these are higher-order operands with usage inspection."

and in the Note we say:

"In practice the rules depend very little on the from and count patterns. This is because when the instruction is applied to a streamed node, the instruction will be free-ranging regardless of these patterns; while if it is applied to a grounded node or atomic value, the instruction will be motionless regardless of the values of these patterns. The only restriction is that the patterns must not reference a grouping variable."

and under 19.8.9 Classifying Patterns (http://www.w3.org/TR/xslt-30/#classifying-patterns) we have a whole bunch of rules that designate a pattern such as foo[bar] as free-ranging.

It appears to me that these rules are in conflict. On one hand you could analyse the pattern and say "hey, this is not classifying", on the other hand you can analyse xsl:number having a grounded select-expression and allow any free-ranging pattern (provided it doesn't use a bound variable).

I don't think the rules are in error here per se, but I do think that when a pattern is used and should not be analysed as a pattern, we should say something about it. Or maybe we already say so elsewhere?
Comment 1 Michael Kay 2014-02-06 11:49:47 UTC
I'm having difficulty understanding what point you are trying to make here. You seem to be suggesting in your last para that the Note is not wrong, in which case your objection is presumably that it is not helpful.

I think there is possibly a bit of a gap in terms of understanding how patterns work as operands (because there aren't many cases where this happens).

We're only concerned with the case where @value is absent.

If @value is absent and the instruction selects a node in the streamed document (that is, if the posture of @select is anything other than grounded), then the fact that @select has usage=navigation will make the instruction free-ranging regardless of the other operands.

If @value is absent and @select is grounded, then the only way the two patterns can make the instruction non-streamable is if they use a "group" variable to refer to streamed nodes.

Perhaps it would be better to spell more of this out here, and rely less on the GSRs.
Comment 2 Abel Braaksma 2014-02-07 13:09:31 UTC
I think the point I was trying to make is that we have rules for Classifying Patterns, and that these rules do not apply to xsl:number, because either the patterns are applied to a grounded note (hence you can use a free-ranging pattern except for bound vars), or they are free-ranging (meaning, even a classified pattern is not allowed).

This distinction between patterns elsewhere and patterns in xsl:number is not clear, though when you follow the rules to the letter, you won't really hit this problem. It is just confusing.

Suggestions for improvement: under Classifying Patterns, we could write that they do not apply to patterns in xsl:number. Vice versa, under xsl:number we could write that the section classifying patterns does not apply.
Comment 3 C. M. Sperberg-McQueen 2014-02-12 09:24:45 UTC
We discussed this in Prague.

There was agreement that the inapplicability (or:  practical inapplicability) of the general rules for patterns to the from and count patterns could usefully be noted explicitly here (and possibly also in the section on patterns).

We also came to believe that (if references to current group and current group key are disallowed, as we have discussed in other contexts) rule 4 might be irrelevant.  If we persuade ourselves to be really confident that it's irrelevant, it could usefully be omitted.

(A similar point applies to 1.f under for-each-group, which is in a similar situation.)
Comment 4 Michael Kay 2014-05-15 13:53:10 UTC
Unfortunately we have introduced a new complication in the form of streamable functions: the "from" and "count" patterns can now contain a variable reference to the streaming parameter of a streamable function. I have proposed in email [1] that when such a reference appears in a higher-order operand then it should be free-ranging/roaming. The constructs therefore need to be included in the analysis so that this situation is detected. The problem of references to grouping variables has disappeared, of course, and there is an explicit rule that current-group() cannot be used in a pattern.

I propose to change the Note to:

In practice the rules depend very little on the from and count patterns. This is because when the instruction is applied to a streamed node, the instruction will be free-ranging regardless of these patterns; while if it is applied to a grounded node or atomic value, the instruction will normally be motionless regardless of the values of these patterns. The pattern does matter, however, if it contains a variable reference bound to the streaming parameter of a function that is declared streamable; because such a reference occurs within a higher-order operand, its presence automatically makes the variable reference free-ranging and therefore means that the function as a whole is not guaranteed streamable.




[1] https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014May/0023.html (member-only)
Comment 5 Abel Braaksma 2014-05-15 22:52:01 UTC
I concur to the solution in comment#4.
Comment 6 Michael Kay 2014-06-05 16:48:07 UTC
The change in comment #4 was accepted.