All the standard attributes (including xsl:use-when) have values that are known statically and have no dependence on the input data to the stylesheet. They are therefore not "constructs", are not operands of any construct, and only play any role in streamability if they affect the semantics of the expression on which they appear, in which case they should be mentioned in that context. But frankly, I think the spec doesn't say anything about them because there is nothing to say.

>Likewise, a note that any attribute not being an AVT or an expression has no
relevance for streamability, i.e. has no operand role, is perhaps beneficial
and clarifying.

I think we list the things that ARE operands, we don't need to list the things that aren't.

I concur :)

We discussed this briefly in Prague and concurred with comments 1 and 2.

Closed with no action.

Unfortunately, I have to reopen this bug. There is one standard attribute, while not an operand, that does influence streamability: [xsl:]version.

Currently, we don't say anything about backwards compatibility processing and streaming. But certain XPath expressions work differently when the effective version of a construct is 1.0. For as far as I can see, it actually works in favor or streamability: more expressions are streamable in 1.0 mode than in other modes.

Take for instance a crawling expression and put it in an absorption context, like string(a//b). In 3.0 (and 2.0) mode, this is not streamable (and will likely raise a runtime error). In 1.0 mode, it is streamable, because the first element will be returned.

I do not suggest we expand our rules for the odd case that someone chooses XPath backwards compatibility mode on streamable expressions, but I do think we should say something about it. My proposal would be to add a note, something along those lines:

Note:
This section does not attempt to define streamability rules for constructs that operate in XPath 1.0 backwards compatibility mode. It is believed that the rules in this section apply both to 1.0 backwards compatibility and normal processing, however, behavior under 1.0 backwards compatibility is considered implementation defined. This allows, for instance, for implementations to optimize expressions such as string(a//c) and make them streamable under 1.0 processing, because it is known at compile time that a//c will always only return the first matching node.

See also bug 25185, which, if accepted, would automatically allow this optimization without having to take into account backwards compatibility behavior.

Changed the title of the bug to reflect that it's now addressing a different problem. Previous titls was

Standard attributes are missing in streamability analysis.

I agree we need to say something about the interaction between streamability and 1.0 compatibility. My preference would be to ban the combination, for example by an overarching rule that says any construct for which 1.0 compatibilty is enabled is roaming and free-ranging.

Note, one case where 1.0 mode makes streaming tricky (though not impossible) is the rule for booleans in a general comparison. The 1.0 rule is that the semantics for comparing an operand that is a singleton boolean are quite different from the rules for a sequence whose first item is a boolean; evaluation therefore requires some look-ahead.

I think my recommendation in the previous comment works: any construct for which 1.0 compatibilty is enabled is roaming and free-ranging.

I agree, it makes sense to ban XSLT 1.0 compatibility in streaming scenarios. I don't see a use-case for it, after all, anything streaming was not available by the language prior to XSLT 3.0, so it doesn't make sense to allow fallback to XSLT 1.0 behavior.

Accepted that we should make backwards-compatible code non-streamable.