W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2016

[Bug 29472] [XSLT30] Optionally allow xsl:stream to process a document *without* streaming

From: <bugzilla@jessica.w3.org>
Date: Thu, 18 Feb 2016 12:19:30 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29472-523-KitnxtnYQZ@http.www.w3.org/Bugs/Public/>

--- 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:

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.

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":


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:59 UTC