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.

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.

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.)

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)

I concur to the solution in comment#4.

The change in comment #4 was accepted.