Saxon

The samples are using imports such as

<xsl:import href="plugin:org.dita-community.common.mapdriven:xsl/dataCollection.xsl"/>

which appear to depend on a custom URIResolver or catalog.

So I added -catalog:DITA-OT2.x/catalog-dita.xml which triggered the failure.

The offending reference is at line 179 of DITA-OT2.x/plugins/org.dita4publishers.epub/xsl/map2epubNavImpl.xsl

This is in the match pattern of a simple template rule

<xsl:template mode="epubtrans:generate-nav-loa 
                      epubtrans:generate-nav-loi 
                      epubtrans:generate-nav-lot 
                      epubtrans:generate-nav-lov 
                      epubtrans:generate-nav-custom 
                      epubtrans:generate-nav-landmarks
                      " 
                      match="*[df:class(., 'map/map')]"
                      priority="-1" 
    >
    <xsl:param name="doDebug" as="xs:boolean" tunnel="yes" select="false()"/>
    <xsl:param name="navType" as="xs:string" tunnel="yes"/>

    <li>Navigation type <xsl:value-of select="$navType"/> not implemented.</li>

  </xsl:template>

whose main notable feature is that it appears in multiple modes.

The first attempt to allocate a binding slot for userFunctionCall#19310 is during allocateAllBindingSlots on mode generate-nav-custom. The second is while processing mode generate-nav-lot. Both modes are using the same Pattern object. It needs to have a separate copy for each mode so that different binding slots can be allocated.

(Note that the fix for bug #3645 prevented a Pattern being processed twice within the context of a single Mode. It didn't prevent it being processed twice for different Modes - nor should it, because different binding slots are needed in each Mode.)

A side observation: these patterns using [df:class(., 'map/map')] as a predicate destroy all our attempts at optimizing the match patterns that were used in the DITA 1.0 stylesheets using contains(). The df:class function is

<xsl:function name="df:class" as="xs:boolean">
    <xsl:param name="elem" as="element()"/>
    <xsl:param name="classSpec" as="xs:string"/>

      <!-- '\$" in the regex is a workaround for a bug in MarkLogic 3.x and for a common user
         error, where trailing space in class= attribute is dropped.
      -->
    <xsl:variable name="normalizedClassSpec" as="xs:string" select="normalize-space($classSpec)"/>
    <xsl:variable name="result"
       select="matches($elem/@class,
                       concat(' ', $normalizedClassSpec, ' | ', $normalizedClassSpec, '$'))"
       as="xs:boolean"/>

    <xsl:sequence select="$result"/>
  </xsl:function>

which no longer uses contains(), it now uses matches(), and moreover it uses matches() with a regular expression that is going to be recompiled on each call. It's a bit of a shame if this is only being done because of a bug in MarkLogic...

Thanks for the comment on the "df:class" function, I contacted the XSLT developer to let him know of the discussion.