[Bug 29733] New: [xslt 3.0] Why you can't pass streamed nodes to the second argument of a streamable stylesheet function


            Bug ID: 29733
           Summary: [xslt 3.0] Why you can't pass streamed nodes to the
                    second argument of a streamable stylesheet function
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

Consider the example in

Example: An absorbing stylesheet function with two arguments

<xsl:function name="f:compare-size" as="xs:integer" streamability="absorbing">
  <xsl:param name="input0" as="node()"/>
  <xsl:param name="input1" as="node()"/>
  <xsl:sequence select="count($input0//*) - count($input1//*)"/>

We state:

Not streamable: f:compare-size(a, b) where a is an element in an unstreamed
document and b is an element in a streamed document

The explanation given is:

"The reason for the asymmetry is that the rules given in
Streamability of Variable References treat the variable references $input0 and
$input1 differently: the rules assume that $input1 will not be bound to a
streamed node."

This explanation doesn't hold water. The rules for variable references say that
$input1 is grounded and motionless. The actual reason is that for an absorbing
function call, the GSRs apply, and the operand usage for the second argument is
navigation, and it's pretty much a consequence of the GSRs that the supplied
expression for a navigation operand must be grounded.

We should change the explanation: "The reason for the asymmetry is that for the
first argument the operand usage is absorption, while the for the second it is
navigation:  the GSRs ensure that when streamed nodes are supplied to an
operand with usage navigation, the resulting expression is roaming and

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

Received on Friday, 15 July 2016 10:43:58 UTC