[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 #8 from Michael Kay <mike@saxonica.com> ---
We dug a very deep hole for ourselves when discussing this, and I'm really not
sure why.

I really think there is a very strong case for having an instruction that does
exactly the same thing as xsl:stream except for the streaming.

In the particular example I've been addressing today, I want to compare the 
performance characteristics of a streaming implementation with a non-streaming
implementation (and at the same time check that the results are the same),
before deciding which to use. In due course, I might decide that I want the
stylesheet to be able to operate either way.

With other constructs in the language, I can switch between streaming and
non-streaming versions of my code by setting streamable=yes|no, for example on
xsl:mode and xsl:merge-source. I really can't see why there is resistance to
allowing the same thing here. Sure, it's difficult to define the precise
semantics, but that applies to the streaming machinery in its entirety.

Sure, I could have a command-line flag that says "implement xsl:stream without
streaming". But setting options from the outside environment can be very
inconvenient, and can be too coarse-grained (it applies to all xsl:stream
instructions, not just one).

For the time being I've implemented an extension attribute to achieve this. But
I really think it should be a standard option, as it is elsewhere.

If the xsl:stream instruction had been named xsl:process-document, and had been
in the language before we started work on streaming, then I don't think we
would have had any hesitation in adding a streamable="yes|no" attribute to the
instruction.

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

Received on Friday, 1 July 2016 17:32:38 UTC