- From: <bugzilla@jessica.w3.org>
- Date: Thu, 10 Mar 2016 13:51:57 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29472 --- Comment #7 from Abel Braaksma <abel.braaksma@xs4all.nl> --- On (a) and (b) I agree with enthusiasm to the proposed changes, these are good options and fix the XML Prague dilemma we faced during the workshop. On (c) I understand the reluctance, but it also offers a way out for situations where otherwise differences between processors would yield a streamable stylesheet in one processor and a non-streamable one in another. In the case of "strict", processors can always choose to do (some) analysis prior to expression-rewriting (we carry the streamability properties of a construct along when doing the rewriting, for instance). I would prefer to have this option, but be lenient about the details. "strict", I think, should be the only one that is required to be supported. "fallback" would be nice to have, and is a big opportunity for easier transition from non-streaming to streaming stylesheets (envision processors doing an implicit copy-of for non-streamable constructs, for instance). "extended" or "optimistic" I would like to allow processors to raise a dynamic error. I.e., this fixes the situation where a user knows that the XML is streamable because it knows the document, the processor can use a strategy where it tries to stream it, but if it finds it must "look back", it raises a dynamic error. (it may still raise a static error if the processor knows it cannot possible stream it, i.e. with an xsl:sort on a streamed node). We have had these options for a while now, I think it is good to make them part of the language, not just API-dependent options (either with or without this attribute, it won't be very easily testable, so this doesn't change that status-quo). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 10 March 2016 13:51:59 UTC