- From: <bugzilla@jessica.w3.org>
- Date: Thu, 18 Feb 2016 12:19:30 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29472 --- Comment #3 from Michael Kay <mike@saxonica.com> --- I agree, xsl:stream/@streamable = yes|no seems the best option available, even though it looks odd. Presumably the effect of @streamable="no" is to switch off both the check for guaranteed streamability, and streamed execution. We discussed the relationship to the rule in 19.10: <quote> If a construct is declared as streamable but is not guaranteed-streamable (that is, if it fails to satisfy the conditions for streamability defined in this specification), then the processor must be prepared to do any one of the following at user option: 1. Signal a static error [see ERR XTSE3430] 2. Process the stylesheet as if it were a non-streaming processor (see below) 3. Process the stylesheet with streaming if it is able to do so, or signal a static error [see ERR XTSE3430] if it is not able to do so. </quote> Noting also that option (1) is a feature-at-risk. If we want XSLT syntax to control the choice between these three options, rather than relying on unspecified implementation-defined syntax as we do now, then we might consider these as additional values of "streamable": streamable="yes-strict" streamable="yes-fallback" streamable="yes-optimistic" Recall also that we suggested in discussion that in option (3), we might want to change the word "static" to "static or dynamic" - that is, to allow processors to adopt an optimistic strategy where streaming might fail dynamically under some input conditions. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 18 February 2016 12:19:33 UTC