24506 2014-02-05 03:38:17 +0000 Impact of [xsl:version] on streamability analysis 2014-06-05 18:11:59 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike cmsmcq public-qt-comments oldest_to_newest 99738 0 abel.braaksma 2014-02-05 03:38:17 +0000 Should we say something about standard attributes in respect to the streamability analysis? The expression in xsl:use-when is obviously irrelevant, but xsl:default-mode influences streamability, as does xsl:expand-text. Not sure this is required, but currently we don't mention them at all under 19.8.4. 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. 99763 1 mike 2014-02-05 10:48:08 +0000 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. 100285 2 abel.online 2014-02-11 15:08:35 +0000 I concur :) 100287 3 cmsmcq 2014-02-11 15:13:33 +0000 We discussed this briefly in Prague and concurred with comments 1 and 2. 100602 4 mike 2014-02-14 17:48:01 +0000 Closed with no action. 103060 5 abel.braaksma 2014-03-27 23:41:30 +0000 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. 104348 6 mike 2014-04-24 14:23:53 +0000 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. 106044 7 mike 2014-05-15 14:42:30 +0000 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. 106125 8 abel.braaksma 2014-05-16 00:25:19 +0000 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. 107379 9 mike 2014-06-05 16:43:03 +0000 Accepted that we should make backwards-compatible code non-streamable.