Saxon » SaxonJS

When I change the variable to use a different name than the parameter as in e.g.

  <xsl:template match="table">
    <xsl:copy>
      <xsl:iterate select="row">
        <xsl:param name="row" as="element(row)?" select="()"/>
        <xsl:on-completion select="$row"/>
        <xsl:variable name="new-row" as="element(row)">
          <xsl:apply-templates select="."/>
        </xsl:variable>
        <xsl:copy-of select="$new-row"/>
        <xsl:next-iteration>
          <xsl:with-param name="row" select="$new-row"/>
        </xsl:next-iteration>
      </xsl:iterate>
    </xsl:copy>
  </xsl:template>

Saxon-JS manages to output the third row two times so the bug only seems to occur due to that use of the same name for variable and param.

Thanks for reporting. Which compiler are you using?

I run it directly the xslt3 command line tool of Saxon-JS, thus it is the compiler of Saxon-JS

"XX compiler" is the name of the compiler (now that I could look it up in the Saxon-JS documentation online :)).

It seems that the xsl:param $row is allocated slot 0, and the xsl:variable $row is allocated slot 1. The variable reference in xsl:on-completion is correctly referencing slot 0, but the xsl:next-iteration/xsl:with-param is binding the new value of the parameter to slot 1.

I notice that in variables-and-params.xsl line 54 the code

            <xsl:if test="parent::xsl:next-iteration">
                <xsl:variable name="param" select="ancestor::xsl:iterate[1]/xsl:param[@name eq current()/@name]"/>
                <!-- Typechecking performed in xpath phase -->
                <xsl:sequence select="$param/(@as|@ex:asJ)"/>
            </xsl:if>

looks questionable because it should be comparing the variable names as QNames. But this isn't the source of the problem. And perhaps it's not a problem anyway - variable names might have been turned into EQNames by this point in the processing.

It looks to me as if the offending code is at xpath.xsl line 262:

           <xsl:if test="self::ex:withParam">
                <xsl:attribute name="slot" select="($local.variables(@name)[2], 0)[1]"/>
            </xsl:if>

This is setting withParam/@slot to the slot number allocated to the in-scope variable named $row, which in this case is NOT the matching xsl:param.

(Note, I don't think it makes sense to allocate a slot on withParam when it's an apply-templates or call-template instruction, because the parameters are then matched by name at run-time. But it probably does no harm.)

Added XSLT3 test case iterate-043.

It seems that at the point where we generate the withParam (xpath.xsl line262) the slot number allocated to the corresponding PARAMDEF is not available. The slot numbers aren't present in the XML tree used as input to this phase of processing, and although there's a tunnel parameter containing the mapping from in-scope variables to slot numbers, this doesn't include the relevant parameter because it has been shadowed by the local variable.

The options appear to be either (a) adding another tunnel parameter explicitly to contain the slot numbers of xsl:param elements, or (b) fixing up the slot number of the withParam in a subsequent processing phase.

Taking the second option, the following fix appears to work. In component-bindings.xsl, add the rule

  <!-- Bind xsl:next-iteration/xsl:with-param to the slot number of the corresponding xsl:iterate/xsl:param -->
  <xsl:template match="ex:nextIteration/ex:withParam" mode="process-bindings">
        <xsl:copy>
            <xsl:sequence select="@*"/>
            <xsl:attribute name="slot" select="ancestor::ex:iterate[1]/ex:params/ex:param[@name=current()/@name]/@slot"/>
            <xsl:apply-templates select="*" mode="#current"/>
        </xsl:copy>
    </xsl:template>

This probably makes the existing code in xpath.xsl redundant.

Not fully tested as I don't have a fully working build environment on my current machine.

The xsl:iterate instruction is not being processed during this phase of processing because of the rule (in component-bindings.xsl)

<xsl:template match="ex:co | ex:accumulator | ex:key" mode="process-bindings">

which takes a fast path by copying the template unchanged if it contains no references to external components. The conditions for this fast path need to be extended.