Saxon » SaxonJS

Consider the commented-out code at https://github.com/gimsieke/xpathle/blob/main/xpathle-lib.xsl#L184

It’s now https://github.com/gimsieke/xpathle/blob/main/xpathle-lib.xsl#L256

Thanks Martin for investigating and for preparing a minimal test case!

SaxonCS/EE seems to compile the intersect check into something like exists(among(..)) while SaxonJS seems to compile intersect in the XSLT/XPath into intersect in the SEF as well. But I have now tested that a template matching element nodes instead of attribute nodes and using the same intersect test gives the same SEF compilation with exists(among(..)) with SaxonCS/EE but that SaxonJS executes that test fine with element nodes. The SaxonJS among function in the end seems to do === which I think, in terms of JavaScript objects like nodes should do an identity check but from the minimized/garbled source I am not able to see/figure what kind of arguments are processed.

In terms of among with element nodes it indeed seems that two DOM element nodes end up being compared with ===, but as SaxonJS seems to handle attribute nodes differently it appears some wrapper/closure around the node ends up being compared and these wrappers/closures, even if having the same attribute node (data) inside (e.g. id="el1") compared with === are not the same objects so the comparison returns false. That seems to be basically the reason why the SaxonCS/EE compiled test=". intersect $nodes" fails with . being attribute node and attribute nodes being in $nodes, it does some comparison with among doing some === comparison failing to identify identical attributes as not a DOM attribute node (reference) is compared with another DOM attribute node reference but two SaxonJS data structures that are not the same object but reference the same attribute fail the === comparison.

Replacing the code in among doing return S===T with return S instanceof Node ? S===T : S.parent === T.parent && S.name === T.name && S.namespaceURI === T.namespaceURI} seems to fix the attribute handling. But I have no idea whether it breaks other things or which other type of wrappers for which the second part after the colon doesn't make sense could be passed to the function.

The basic problem is that we are using a === b to compare nodes for identity, and this doesn't work for attributes because the attribute axis constructs attribute nodes "on the fly". We should be using DomUtils.isSameNode(a, b).

The "among" operator is basically an optimisation for a one-to-many intersect. This is most commonly encountered in a boolean context

if (X intersect (P, Q, R))

and the main benefit of the optimisation is to avoid sorting nodes into document order. The XJ compiler does this optimisation; XX does not.

Come to think of it, the code for "among" has another bug. If we don't sort the sequence into document order, and don't eliminate duplicates, there's a danger that (P intersect (P, Q, R, P)) is going to return (P, P). rather than (P).

Added a QT3 test case for this: -s:op-intersect -t:K2-SeqIntersect-48

SaxonJ is passing the test because it effectively rewrites the expression as

((P, Q, R, P)[. is P][1])

That is, it knows the expression can return at most one node so it stops processing the input after one node has been found.

I'm inclined to fix this by scrapping the SingletonIntersectExpr ("among" operator) in SaxonJ, rewriting instead as

let $x := §ARG0§ return head(§ARG1§[. is $x])

and dropping support for "among" in SaxonJS 3 (SEF files will probably need to be recompiled for SaxonJS 3 anyway).

Reducing the number of instructions is always good, as each instruction now carries a lot of code and potential bugs (bytecode, streaming, etc).

I think the "quick fix" is simply to change the code at Expr.js#89 (in my build) from

node === m

to

DU.isSameNode(node, m)

(But check for the potential bug identified in comment #9)