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

[Bug 29467] [xslt30] Non-streaming fallback implementation of xsl:stream

From: <bugzilla@jessica.w3.org>
Date: Tue, 16 Feb 2016 11:17:29 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29467-523-m854KGVjcz@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29467

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
We found this Note in 18.1:

The name of the instruction reflects its intended usage, to process an input
document using streaming. However, a processor that does not offer the
streaming feature must still implement the instruction (without being required
to use streamed evaluation or to check its streamability); and processors that
do offer the streaming feature are also required to provide a mode of execution
in which the construct is evaluated without streaming if it fails the
streamability criteria.

Also noted that 19.10 says:

For a non-streaming processor, the processor must evaluate the construct
delivering the same results as if execution used streaming, but with no
constraints on the evaluation strategy.

It also says: "For a streaming processor, that is, a processor that claims
conformance with the streaming feature: ... If a construct is
guaranteed-streamable then it must be processed using streaming." 

So perhaps all that is needed is an API switch to say "run as a non-streaming
processor"?

So we believe the requirement stated in this bug entry is already satisfied by
the spec. A directive with similar effect within the stylesheet itself could be
useful, but is not essential to meet the requirement.



Related to this (but not directly relevant...) is the rules for what a
streaming processor must do when the construct is not streamable. In 19.10 we
say

2(c) 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.

It might be useful to permit the processor to fail with a dynamic error if
streaming is not possible (i.e. allow it to attempt streaming optimistically,
wher e success or failure depends on the nature of the input data). E.g.

2(c) Initiate processing with streaming, raising a static error if it can
determine statically that this will not be possible, or a dynamic error if the
attempt to use streaming fails dynamically.

We will raise this as a separate issue, and close this one with no action.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 16 February 2016 11:17:32 UTC

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