[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 #1 from Michael Kay <mike@saxonica.com> ---
I've been arguing for relaxation of this rule for a long while. To implement
the rule in its current form, in principle you have to do streamability
analysis on the expression tree before you do any other rewriting of the tree.
Since streamability analysis depends on things like binding variable
references, binding function references, and doing a certain amount of type
analysis, this is a pretty tough demand.

Note also that this is explicitly a requirement that is "at risk" ("The
requirement for every processor to report any departure from guaranteed
streamability, even in cases where the processor is able to use streaming
anyway.")

I would suggest adding the rule:

"The requirement to report a static error where a construct A is not
guaranteed-streamable does not apply in cases where the processor is able to
determine in the course of static analysis that the construct A is semantically
equivalent to a construct B where B is guaranteed-streamable."

Note that this does not license relaxation of the rules as to what constructs
are guaranteed streamable, it only permits static rewrites prior to
streamability analysis. 

However, it's quite a wide exemption: for example (PRICE - DISCOUNT) is not GS,
but it can be rewritten as (let $M := map{1:data(PRICE), 2:data(DISCOUNT)}
return ($M?1 - $M?2)) which is GS.

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

Received on Sunday, 6 November 2016 14:46:59 UTC