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

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

--- Comment #6 from Michael Kay <mike@saxonica.com> ---
I would be inclined to go with the following.

(a) A new attribute xsl:stream/@streamable="yes|no". The default is yes.

(b) In 19.10, change:

The xsl:stream instruction implicitly declares that its contained sequence
constructor is streamable;

to

The xsl:stream instruction implicitly declares that its contained sequence
constructor is streamable except when the attribute streamable=no is specified.

(Note: a non-streaming processor already executes the xsl:stream instruction
without actually streaming. Setting streamable=no causes a streaming processor
to behave like a non-streaming processor; in particular, it does not check that
the construct is guaranteed streamable.)

I looked at the following idea:

(c) On xsl:stylesheet/xsl:package, add

@streamability = strict | fallback | extended

The attribute defines the action of a streaming processor when the stylesheet
contains a construct that is declared streamable but not guaranteed streamable.
The values are

1. strict: Signal a static error [see ERR XTSE3430]

2. fallback: Process the stylesheet as if the processor were a non-streaming
processor (see below). Note that non-streaming processors are allowed to use
streaming if they choose, so this does not necessarily imply a non-streamed
evaluation.

3. extended: Process the stylesheet with streaming if it is able to do so, or
signal a static error [see ERR XTSE3430] if it able to determine statically
that it cannot do so.

(d) relate these three options to the (a,b,c) options in 19.10.

But on balance, I'm reluctant. I think it's hard to pin down the semantics
here. We don't define "streaming" precisely, there are many hybrid strategies,
and it's ultimately a matter of judgement whether a particular strategy counts
as streaming or not. It also interferes with the general rule that
implementations are always allowed to attempt streaming if they choose, and
they are always allowed to fail if they run out of resources.

My own preference (as anticipated in the "features at risk") is to change the
sentence

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:

to

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 may do any one of the following (and may
give users control over which option is chosen):

As I've said before, Saxon's streamability rules will give the same answer as
the W3C streamability rules in 99% of cases, but I don't think it's possible to
achieve 100%; there will always be cases that aren't streamable according to
the W3C rules but where Saxon doesn't detect the non-streamability, and that's
because we do a lot of expression rewriting before we assess streamability. So
I think defining attributes that purport to give even finer control over
streaming behaviour is the wrong direction to go in; the semantics of such
attributes are almost impossible to define in a way that is objectively
testable.

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

Received on Thursday, 10 March 2016 13:10:35 UTC