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

[Bug 29984] [XSLT30] Lessen the restraint on required raising of XTSE3430 for constructs not guaranteed streamable per our rules

From: <bugzilla@jessica.w3.org>
Date: Sun, 06 Nov 2016 17:37:07 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29984-523-GJAtDeOVDN@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29984

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I think the aim we should have is to widen the rules to those cases that can be
statically assessed. Option (3), in comparison, is to "attempt streaming if you
can", which we take as "optimistic streaming" (i.e., a user knows more of the
data model than the processor does, so you can just try and see how it goes).

The underlying proposal here would instead widen what I call "pessimistic
streaming" (option 1), which means, only if you are dead certain you stream,
and you have to be certain during static analysis, then you are *not required*
to raise XTSE3430.

Your proposal on "static rewrites" is wider than my proposal that only assesses
cases where access to nodes is considered. I look forward to a discussion on
this, perhaps we finally come to something that is both strict *and* allows
processors a certain freedom in parsing and optimizing.

This proposal may also make XSLT 3.0 more future proof. By cementing the rules
we kinda prohibit advances in streamability and big data analysis with XSLT. By
allowing leniency, new research, real-world scenarios and processors playing
catch-up with one another can advance the applicability of streaming XSLT and
(big) data mining in general.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 6 November 2016 17:37:14 UTC

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