Saxon » SaxonJS

Interesting, using <xsl:map-entry key="data(//bar)" select="'greeting'"/> instead of <xsl:map-entry key="string(//bar)" select="'greeting'"/> gives the error Cannot read property 'hashCode' of null with Node.js or Cannot read properties of null (reading 'hashCode') in the browser.

As you mention you also use oXygen, have you tried to use Saxon 9.9.1.7 to compile/export an SEF for Saxon-JS and then check whether Saxon-JS doesn't produce the error?

I have put this into a new XSLT3 test maps/maps-017.

Confirmed that it fails under node.js as described.

Looking at the SEF file, if we use //bar in the select attribute, it compiles as

{
     "N": "axis",
      "name": "descendant",
      "nodeTest": "*NE nQ{http://www.example.com}bar"
 }

whereas in the key attribute it compiles as

{
     "N": "axis",
      "name": "descendant",
      "nodeTest": "*NE nQ{}bar"
 }

So the bug is in the XX compiler.

I suspect that in maps.xsl line 32

<xpath role="key" xpath="data({@key})" line="{f:line-number(.)}"/>

should be

<xsl:apply-templates select="@key" mode="create.xpath"/>

except I'm not sure how we achieve the atomisation: perhaps with a $type or $checkType parameter? This invokes the template rule in XSLT-SEF-compiler.xsl line 1819, which picks up the tunnel parameter xpath-default-namespace.

There are other places that appear to generate an <xpath> instruction directly without taking account of xpath-default-namespace, these include

• xsl:key/@use (key.xsl line 29)
• xsl:for-each-group/@group-by (grouping.xsl line 73) (But @group-adjacent on line 88 handles the xpath-default-namespace directly, perhaps we could follow that example - it's also used for xsl:number/@value in numbering.xsl line 32))
• ixsl:set-attribute, remove-attribute etc = ixsl.xsl lines 22, 35, 36, 49, 62, 76, etc

Note also, if we do use "data({@key})" to achieve atomisation, it should be "data(({@key}))" to allow for something like key="$x, $y".

I also added tests key/key-099 to test for default namespace in xsl:key/@use -- which fails, and for-each-group/for-each-group-091 - which succeeds.

As suggested in comment #3, there was indeed a problem with atomisation (leading to the error $key$$.hashCode is not a function).

The atomization can be forced by changing the apply-templates call to

            <data>
                <xsl:apply-templates select="@key" mode="create.xpath"/>  
            </data>

Looking at the SEF file produced for key-099, (a) for the XX compiler, the "use" attribute of xsl:key seems to lack the default namespace, but (b) for the XJ compiler, it looks fine.

I've changed the XX compiler at key.xsl#32 in the same way as comment #7, and the test is now working.

But the XJ-compiled test still fails...

Running the test transformation outside the test driver works, however, so I think I've got a problem with my configuration for running the test driver.