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 11:59:13 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29472-523-CjAKnW376x@http.www.w3.org/Bugs/Public/>

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
One of the main problems here is that it is (probably) not possible for a
processor to create an extension attribute for this, because it is not allowed
to violate default behavior of xsl:stream. If we decide that we should leave it
to implementers, we should open up the conformance section to allow such an

Additionally, part of the discussion was on the topic of such an option for
xsl:mode and xsl:merge-source as well. I think the main use-case is for
xsl:stream, as for xsl:mode and xsl:merge-source a switch can be used by the
programmer through shadow-attributes with _streaming="{$use-streaming}" and
then streaming on/off can be set globally.

For xsl:stream such an option does not exist. In hindsight, something like
<xsl:process streamable="yes" source="streameddoc.xml"> might have been a more
configurable syntax.


We might consider <xsl:stream streamable="yes|no"> where the default is "yes".
I think this would serve most use-cases. It looks a bit odd, but is in line
with other instructions that support streaming, hence I think it fits in our
orthogonality principles. It should *not* be an AVT, otherwise static analysis
becomes problematic, but as shadow attribute it is then statically

Having this in place, a user can set one global static parameter, say
$use-streaming, and use that as a shadow attribute in all xsl:mode,
xsl:merge-source, xsl:accumulator, xsl:stream, xsl:global-context-item
instruction and declaration. It solves the main use-case from the workshop: to
test the whole stylesheet without streaming and streamability analysis, and
then, once it works, with streaming by switching the static parameter.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 18 February 2016 11:59:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 18 February 2016 11:59:16 UTC