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

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 08 Jul 2016 07:53:35 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29472-523-pUm46pQWZx@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29472

--- Comment #10 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to C. M. Sperberg-McQueen from comment #9)
> A simple proposal (but not necessarily a non-controversial one):
> 
> 1 We seem to be in agreement that allowing the xsl:source instruction
> to carry a streamable attribute would improve the parallelism between
> it and other constructs and thus improve the design of the spec.
I am in favor or renaming xsl:stream to xsl:source or xsl:doc or
xsl:source-document or something similar that removes the perceived semantics
that xsl:stream starts streaming. That way I think much of the controversy goes
away and it brings the instruction in line with other instructions that have
the @streamable attribute.

> 2 We seem to be in agreement that this does not, strictly speaking,
> require conforming processors not to stream the data.
I agree. This bug report was inaptly worded. It should be noted that when I
wrote "switch OFF streaming", it meant: "remove the requirement to do
guaranteed-streamability checking (if you claim conformance with 19.10) and
stream the input as per the rules in section 19.10".

Any processor is always allowed to stream the input (fn:doc, fn:unparsed-text
etc) if it can and wants to, regardless of whether it claims conformance with
section 19.10, regardless whether the @streamable attribute is present.

In fact, we even say that "A non-streaming processor is not required to assess
whether constructs are guaranteed-streamable". Which I think means that they
can check for guaranteed-streamability if they want to.

> Bug 29472 is a request for a way to turn off streaming processing on
> xsl:stream instructions.  If we really do agree on point 2, then bug
> 29472 must be closed as INVALID (or WONTFIX, if we think it would be
> desirable to be able to turn streaming processing on or off).
If that helps I have no problem with that. But I think that in spirit this bug
report was raised with the static streamability checking (per 19.10) in mind.
In comment 8, Michael explains that other use cases can be considered also.

> then we need a new bug, which we can close by adding the
> streamable attribute to xsl:stream (and, if we like, renaming 
> xsl:stream).
I can go either way (new bug, or this one). I have renamed this bug report,
perhaps that helps already. I would vote for renaming xsl:stream.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 8 July 2016 07:53:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:01 UTC