[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 #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'),
2)}"/> 
   </xsl:template>

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(*)}"/> 
   </xsl:template>

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