Saxon » SaxonJS

Interesting, if xslt3 from SaxonJS 2.5 runs the original XSLT stylesheet it gets it right:

C:\Users\marti\OneDrive\Documents\xslt\blog-xslt-3-by-example\map-merge>xslt3 -t -it:test -xsl:test1.xsl
SaxonJS 2.5 from Saxonica
Node.js version v16.17.1
Compiling stylesheet C:\Users\marti\OneDrive\Documents\xslt\blog-xslt-3-by-example\map-merge\test1.xsl
Stylesheet compilation time: 0.289s
Initial template: Q{}test
Asynchronous transform with options: stylesheetText={"N":"package","version":"30",(string), stylesheetBaseURI=file://C:/Users/marti/OneDrive(string), stylesheetParams=[object Object](string), outputProperties=[object Object](string), extraOptions=[object Object](string), destination=stdout(string), baseOutputURI=file://C:/Users/marti/OneDrive(string), logLevel=2(string), initialTemplate=Q{}test(string),
SEF generated by SaxonJS 2.5 at 2023-01-26T00:09:17.156+01:00
fn:trace: submap: HashTrie map{xs:integer('1'): xs:string('a')}
fn:trace: submap: HashTrie map{xs:integer('2'): xs:string('a')}
fn:trace: submap: HashTrie map{xs:integer('2'): xs:string('b')}
fn:trace: submap: HashTrie map{xs:integer('1'): xs:string('c')}
fn:trace: submap: HashTrie map{xs:integer('3'): xs:string('d')}
fn:trace: merged: HashTrie map{xs:integer('1'): (xs:string('a'),xs:string('c')), xs:integer('2'): (xs:string('a'),xs:string('b')), xs:integer('3'): xs:string('d')}
<?xml version="1.0" encoding="UTF-8"?><div>true true true true</div>

So is the Saxon EE compiler to blame?

I've added some further browser tests: iss5855a uses modified syntax (e.g. more use of XSLT rather than XPath); and iss5855b has further simplifications to avoid the use of locally defined functions.

I've also added test map-merge-027 in the QT3 test suite (based on iss5855b). This is useful as we run the test suites with SaxonJS on Node.js as well as in the browser.

The fact that the original test failed with an XJ-compiled SEF but not an XX-compiled SEF suggested that the problem is with the compiler. However further tests and debugging show that the issue is actually in the implementation of map:merge (in ExtraFn.js).

The bug is that when constructing a new merged map (represented internally with a HashTrie), for duplicate keys, we were simply using val.push() to update the existing array value val in the HashTrie, and then replacing the entry using inSituPut:

                        if (dup === "combine") {
                            const val = m.get(pair.k);
                            pair.v.forEach(function (x) {
                                val.push(x);
                            });
                            m.inSituPut(pair.k, val);
                        }

However, in some circumstances, as manifested in this bug, the value in the map entry might be a shallow copy of the array object; so it is not safe to do such a direct update. This can be fixed by ensuring we create a new array for the new value, rather than amending the old one.

The difference in the test results with XX and XJ-compiling is something to do with the difference in the compilation, and somehow the XX-compiled version avoids the bug manifesting. For instance, the use of the map constructor in the this:map-invert function compiles differently: with XJ we get an ifCall to map:entry, but with XX we simply get a map expression. I can't quite see how this makes a difference to avoid/cause the bug, but it at least explains how the results are different.