[Bug 29747] [XSLT30] Allow the attribute xsl:stream/@streamable with a default of "yes"

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29747

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 20 July 2016 19:58:53 UTC