W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2016

[Bug 29482] [xslt30ts] si-group-031

From: <bugzilla@jessica.w3.org>
Date: Thu, 03 Nov 2016 14:01:59 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29482-523-mcb6iiuBB1@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29482

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|XSLT 3.0 Test Suite         |XSLT 3.0
           Assignee|abel.online@xs4all.nl       |mike@saxonica.com

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I am turning this into a spec bug. This is what we say on higher-order
operands:

[Definition: Whether or not the operand is higher-order. For this purpose an
operand O of a construct C is higher-order if the semantics of C potentially
require O to be evaluated more than once during a single evaluation of C.]

The part that doesn't fit with both our analysis is:

"potentially require O to be evaluated more than once during a single
evaluation of C."

This rule has two side effects that we may not have anticipated:

1) if the focus-changing construct changes to a grounded node
2) if the evaluation does not *require* multiple evaluations of O

Example situation 1) (same as this issue)

<xsl:for-each-group 
    select="product" 
    group-adjacent="(position() - 1) idiv $block-size">

    <xsl:result-document href="product{current-grouping-key()}.xml">
        <xsl:copy select="$root">

            <!-- this seqtor is NOT higher-order, the node is grounded -->

            <!-- hence, this is allowed: -->
            <xsl:copy-of select="current-group()"/>
        </xsl:copy>
    </xsl:result-document>

</xsl:for-each-group>

Example situation 2)

<xsl:for-each select="foo[1]">
   <xsl:value-of select="every $x in bar satisfies @zed" />
</xsl:for-each>

-----------

We may want to tighten the rule on higher-order constructs to prevent this, but
we can also leave it as it is, because at least in theory, there is no bug with
the spec, only with our interpretation (we could do with some examples in this
section in the spec, there are none).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 3 November 2016 14:02:10 UTC

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