Saxon » SaxonJS

Using Saxon 2.2.

I think the problem might simply be that the index for a key declaration is built-once but is not later updated when the document is changed. At https://martin-honnen.github.io/xslt/2021/saxon-js-key-test-ee1.html there is an initial value for the key call but it remains constant while a direct attribute based selection does take the actual state of the tree into account. Solely a guess, however.

Note that you seem to use Saxon JS 2.1 despite your statement you tested with 2.2. But I don't think that matters.

You're right, I was still generating SEF with 2.1. Now it should be 2.2 for real.

The key thing is not great then. If ID lookups can work, I would keys expect to work as well. But lets see what Saxonica says :)

As a workaround, I'm trying to call the key on $xhtml to get IDs of those elements and then use id() on ixsl:page().

The strange thing was, unless I'm mistaken, that if I inlined the some-template code directly into the ixsl:onclick handler, it worked as expected. But I don't want to touch it anymore :)

I do recall a known issue/restriction in this area, but I'm having trouble finding any documentation.

For accumulators on HTML documents there is a warning: "Accumulator values are attached to DOM nodes in situ. This means a DOM node can't have different values for the same accumulator name in different transformations. This is likely to be a permanent restriction. Advice for users: do not use accumulators on the HTML document, because it is mutable.".

Perhaps the same holds for keys?

Martin is right that the key index is only built once, but since the HTML page is mutable this is not necessarily good enough. As Mike and Martin have noted, this restriction is unfortunately not documented. So in the short-term, we need to update the documentation to include a warning about the use of keys for nodes in the HTML page.

In the long term, we should improve the implementation so that such keys are actually usable. The key indexes should be rebuilt if the HTML page has any (relevant) changes.

Makes sense. MutationObserver could be useful for tracking DOM changes.

Warning added to the documentation, under conformance/xslt30 (which will be updated online with the next maintenance release).

Any news on this?

How about a new instruction that would rebuild the keys? For example: <ixsl:refresh-key name="lines-by-start"/>

I had to get rid of key() usages because of this issue and replace them with ixsl:page()//... lookup. Rendering an interactive SVG graph with hundreds of nodes, the performance degradation is clearly noticeable :(

My inclination is to resolve this by having the key() function do a straight search (without using indexes) when the target document is mutable. The HTML page is rarely going to be so big that it's going to make a big difference.

Respectfully, that sounds the worst option of all 3 (the other two being automatic key refresh and explicit refresh instruction). Is it so hard to refresh them keys?

In our case all documents are mutable, because navigation is done by Saxon-JS loading and injecting document fragments into DOM.

As mentioned above, I've replaced key() lookup with // on an SVG document with hundreds of elements, and the slowdown was noticeable.