Project

Profile

Help

Bug #4607

closed

Transformation failure from XX-compiled SEF for Saxon-Forms

Added by Debbie Lockett almost 4 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Category:
XX compiler
Sprint/Milestone:
-
Start date:
2020-06-19
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
2
Fix Committed on JS Branch:
2
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

Using an XX-compiled SEF of saxon-xforms.xsl, generated with Saxon-JS 2.0 on Node.js, fails at run time. E.g. in sample1.html from https://github.com/Saxonica/Saxon-Forms

Transformation failure: Error SENR0001 at saxon-xforms.xsl#1025
    Cannot add a map to an XDM node tree

An SEF generated with Saxon-EE 10 seems to work OK.


Files

bug4607.html (747 Bytes) bug4607.html Debbie Lockett, 2020-07-17 23:00
bug4607.xsl (792 Bytes) bug4607.xsl Debbie Lockett, 2020-07-17 23:00
bug4607XX.sef.json (1.89 KB) bug4607XX.sef.json Debbie Lockett, 2020-07-17 23:00
bug4607.sef.json (1.36 KB) bug4607.sef.json Debbie Lockett, 2020-07-17 23:01
Actions #1

Updated by Debbie Lockett over 3 years ago

  • Status changed from New to In Progress

This may not actually be a bug in the XX compiler at all. After some searching, I have pinned down the issue to being a stray xsl:map-entry instruction in the saxon-xforms.xsl stylesheet (at line 2803). When the instruction is removed, an XX-compiled SEF seems to work correctly without errors at runtime.

So there is a question as to why (or how) the XJ compiler and XX compiler handle compilation of this instruction differently, and what the correct behaviour really is, but actually it comes from a coding mistake. See the <xsl:map-entry key="$instance-key" select="$instance-with-explicit-namespaces"/> instruction in the code below. Generally the purpose of the template is to do some side-effect actions (js function calls), rather than write to the current result tree. For some reason it seems the XX compiled version does try to write a map to the current result tree, but the XJ compiled version doesn't.

<xsl:template name="xforms-model-construct">
        <xsl:param name="model" as="element(xforms:model)" required="yes" tunnel="yes"/>
        
        <xsl:variable name="model-key" as="xs:string" select="if (exists($model/@id)) then xs:string($model/@id) else $global-default-model-id"/>
        
        <xsl:variable name="instances" as="element(xforms:instance)*" select="$model/xforms:instance"/>       
        
        <xsl:for-each select="$instances">
            <xsl:variable name="instance-with-explicit-namespaces" as="element()">
                <xsl:apply-templates select="./*" mode="namespace-fix"/>
            </xsl:variable>
            <xsl:variable name="instance-key" as="xs:string" select="if (exists(@id)) then xs:string(@id) else $global-default-instance-id"/>
            <xsl:map-entry key="$instance-key" select="$instance-with-explicit-namespaces"/>
            <xsl:sequence select="js:setInstance($instance-key,$instance-with-explicit-namespaces)"/>
            <xsl:if test="position() = 1">
                <xsl:sequence select="js:setDefaultInstance($instance-with-explicit-namespaces)"/>
            </xsl:if>
            
        </xsl:for-each>
        
         
        <xsl:call-template name="xforms-rebuild">
            <xsl:with-param name="get-bindings" as="xs:boolean" select="true()"/>
            <xsl:with-param name="model-key" as="xs:string" select="$model-key" tunnel="yes"/>
        </xsl:call-template>
        
        <xsl:call-template name="xforms-recalculate"/>
        
    </xsl:template>
Actions #2

Updated by Debbie Lockett over 3 years ago

See attached reduced repro for the issue. The problem seems to be that when the output method is xml, xhtml, html, or text, the XX compiler automatically adds the build-tree="tree" property to this output definition, which the XJ compiler does not. The run-time error then occurs with the XX SEF when a map is added to the principal result tree.

Actions #3

Updated by Debbie Lockett over 3 years ago

  • Status changed from In Progress to Resolved
  • Fix Committed on JS Branch 2.0 added

Patch committed (in Saxon-JS 2 branch) in XX compiler (in static-normalize/normalize.xsl) to remove unconditional addition of build-tree attribute to output definition (when output method is xml, xhtml, html, or text). I can't see any regression caused by this change (XSLT3 and QT3 tests suites have been run).

Tests added to JS2 unit tests on dev branch: bugs/bug4607_01 should not throw error for map in unused principal result tree; bug4607_02 should throw error when principal result tree (with map) is appended to page (with "destination":"appendToPage" in SaxonJS.transform call).

Actions #4

Updated by Community Admin about 3 years ago

  • Applies to JS Branch 2 added
  • Applies to JS Branch deleted (2.0)
Actions #5

Updated by Community Admin about 3 years ago

  • Fix Committed on JS Branch 2 added
  • Fix Committed on JS Branch deleted (2.0)
Actions #6

Updated by Debbie Lockett about 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in JS Release set to Saxon-JS 2.1

Bug fix applied in the Saxon-JS 2.1 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page