This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As per the request in Bug 29472, comment 9, this bug report is to propose the addition of an attribute on xsl:stream, "streamable" with the possible values "yes" or "no" (and true, false, 0, 1) defaulting to "yes". The semantics should be similar to, for instance, xsl:mode/@streamable, in that it triggers the rules specified under section 19.10 if implicitly or explicitly set to "yes".
Let me try and document a rationale/justification for this change. Firstly, I think it's useful to imagine that we had an instruction xsl:source-document that allowed us to write: <xsl:source-document href="books.xml"> <xsl:apply-templates/> </xsl:source-document> Before we even think about streaming, such an instruction would be useful. Unlike the document() function, it could allow control (through attributes) of how the source document is to be processed: for example it could control schema validation, recovery action on failures, operational details such as authentication and timeouts, HTTP request properties, etc etc. If such an instruction had existed in XSLT 2.0, we would have no hesitation in adding a streamable="yes" attribute in XSLT 3.0, with the same semantics we have for the attribute on (say) xsl:merge-source: <quote> Specifying streamable="yes" on an xsl:merge element declares an intent that the xsl:merge instruction should be streamable, either because it is guaranteed-streamable, or because it takes advantage of streamability extensions offered by a particular processor. The consequences of declaring the instruction to be streamable when it is not in fact guaranteed streamable depend on the conformance level of the processor, and are explained in 19.10 Streamability Guarantees. </quote> Having parallel constructs with the same semantics but that use an attribute to control streamability is generally useful. It allows, for example: * easy creation of two versions of a stylesheet, one of which handles small source documents where streaming is not essential, while the other handles large documents where streaming is required. * easy switching of streaming on or off, just as one might switch validation or output indentation on or off. * separation of concerns when doing stylesheet development: first get the functionality right, then worry about how to make it streamable. It has been argued that an operational switch between streaming and non-streaming modes of operation can be implemented externally for example as a command line option. But (a) this is inconsistent with our current design which provides finer-grained control at the instruction level, and (b) it doesn't reflect the fact that specifying streamable="yes" is a declaration of intent to use the streamable subset of the XSLT language. Because this attribute affects what else can appear in the stylesheet, I think it is completely appropriate for it to appear in the stylesheet itself. In an ideal world I think the right design would be to have an xsl:source-document instruction replacing xsl:stream, with the attribute streamable=yes|no defaulting to no, and with the value streamable=yes giving the semantics of the current xsl:stream instruction. If we feel this is too disruptive, then a solution where the instruction is named xsl:stream and has a streamable=yes|no attribute defaulting to yes is completely isomorphic.
This issue is now resolved. The WG decided to replace the xsl:stream instruction with an xsl:source-document instruction having the attribute streamable=yes|no, and to strive for maximum orthogonality between the streaming and non-streaming behaviours of the instruction.