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: Mon, 21 Nov 2016 14:29:58 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29984-523-sGZasqjPUv@http.www.w3.org/Bugs/Public/>

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
Here's an example where the relaxation in the rules would be useful. Test case
accumulator-009s has 

   <xsl:template match="/">
     <result min="{accumulator-after('min')}" max="{accumulator-after('max')}" 
        sum="{accumulator-after('sum')}" count="{accumulator-after('count')}" 
        avg="{round(accumulator-after('sum') div accumulator-after('count'),

Now, despite what I wrote in bug #30018, this is not guaranteed streamable.
Uder ยง19.8.9.1, (accumulator-after() is consuming if there is no preceding
INSTRUCTION that is consuming, therefore the literal result element has two
consuming operands. But if it is rewritten as

<xsl:element name="result">
  <xsl:attribute name="min" select="accumulator-after('min')"/>
  <xsl:attribute name="max" select="accumulator-after('max')"/>

then it become guaranteed streamable. And Saxon does this rewrite at a very
early stage of static analysis, long before streamability analysis.

Changing the rules to make the expression as originally written
guaranteed-streamable is not easy. The reason the rules for accumulator-after()
treat instructions and sequence constructors specially is that there is a
natural order of execution. The rules would also have to handle:

   <xsl:template match="/">
     <result min="{accumulator-after('min')}" size="{count(*)}"/> 

where it is very difficult to define rules that ensure that accumulator-after
can be evaluated after the consuming count(*) expression.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 21 November 2016 14:30:05 UTC

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