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: Sat, 20 Feb 2016 17:22:54 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29472-523-Lrqokj9N4u@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29472

--- Comment #5 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> then we might consider these as additional values of "streamable":

> streamable="yes-strict"
> streamable="yes-fallback"
> streamable="yes-optimistic"

In principle I am in favor of such an option (esp. since we already offer
optimistic streaming, though the option is not documented yet), but I'm also
hesitant, as I'd rather have the stylesheet as a whole be analyzed/processed as
strict/fallback/optimistic.

I'd also favor any library package to have to be strict (for compatibility
reasons), but that may be both an unnecessary restriction and/or hard to define
in spec prose.

For consideration then, I would like to suggest
(xsl:package|xsl:stylesheet)/streamability-level = "strict | fallback |
optimistic", or something of that kind, which is easier to implement at this
stage than trying to define interactions of the several constructs if one is
strict and the other is optimistic. If library packages must be strict and
import precedence is not an issue (only the principle stylesheet module counts)
then I think this could work without being too much of a change, and it
relieves the stress of Rule 1: Raising a static error.

Since fallback and optimistic are implementation-defined, we could define this
such that only "strict" is required.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Saturday, 20 February 2016 17:22:57 UTC

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