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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29984

--- Comment #4 from Michael Kay <mike@saxonica.com> ---
MSMcQ asked (in IRC): But if we are going to remove the interoperability rule
so thoroughly, why are we defining a concept of guaranteed-streamable in the
first place?  If that definition has become pointless, as well as far more
complex than I wish it were, then why not forget it entirely?

My response to that is that the definition is very far from pointless. We are
essentially partitioning stylesheets into three classes:

(A) Those that are guaranteed streamable

(B) Stylesheets that are statically equivalent to stylesheets that are
guaranteed streamable

(C) The rest

and the proposal is to remove the requirement for implementations to
distinguish categories (A) and (B).

>From a usability point of view, I think most users would prefer stylesheets in
category B to be streamed rather than to be rejected: otherwise they will want
to know "why is it streamable if I write it this way, and not if I write it
that way, when the two are obviously equivalent".

>From a purely practical point of view, I don't think it's realistic (for
example) for an implementor to run two sets of static type inference rules over
the expression tree, one to do the best possible optimization of the code, and
one to evaluate exactly the types decreed as input to the streamability rules.
It's a threat I don't like to use, but I do believe that if we keep this
requirement in the spec then we will end up with products that decide not to
conform to this requirement.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 1 December 2016 18:17:37 UTC