[Bug 29984] New: [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

            Bug ID: 29984
           Summary: [XSLT30] Lessen the restraint on required raising of
                    XTSE3430 for constructs not guaranteed streamable per
                    our rules
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

We require a processor to offer a user option to raise the error XTSE3430 when
a construct is not guaranteed streamable per the rules in the specification.

I know this option has had considerable debate in the past, but I would like to
(slightly) lessen this requirement.

Specifically, processors may very well pre-optimize expressions and constructs
if they evaluate to an empty sequence or a constant value. Example:

every $a in foo[false()] satisfies $a[@x = 1]

This is not allowed with streaming (binding a node to a variable). But the set
of $a is empty (replace "foo[false()]" with any expression that is statically
empty).

I wouldn't be surprised if most processors detect this at the parsing phase,
and do not detect it being not guaranteed-streamable (but streamable
nonetheless). I know we miss it.

While I am not certain what exactly we can do here, I am thinking of something
along those lines:

Replace:

[Definition: A guaranteed-streamable construct is a construct that is declared
to be streamable and that follows the particular rules for that construct to
make streaming possible, as defined by the analysis in this specification.]

with

[Definition: A guaranteed-streamable construct is a construct that is declared
to be streamable and that follows the particular rules for that construct to
make streaming possible, as defined by the analysis in this specification, or
any construct that can statically be determined to never require access to a
streamed node but that would otherwise not be guaranteed streamable according
to the rules in this specification.]. Whether or not a processor can determine
statically that a construct does not require access to a streamed node is
implementation-dependent.

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

Received on Sunday, 6 November 2016 10:09:57 UTC