Bug #5036

key() doesn't work on ixsl:page() after ixsl:replace-content?

Added by Martynas Jusevicius 7 months ago. Updated 5 months ago.

In Progress
XSLT Conformance
Start date:
Due date:
% Done:


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


Not sure it's the best subject, but this is what seems to be happening here (see the last 2 templates):

Live demo: Click the [@CLASS KEY] button.

I would expect the lookups to find id('abc', ixsl:page()) (which it does) as well as key('elements-by-class', 'some-class', ixsl:page()) (which it doesn't).


#1 Updated by Martynas Jusevicius 7 months ago

Using Saxon 2.2.

#2 Updated by Martin Honnen 7 months ago

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 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.

#3 Updated by Martin Honnen 7 months ago

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.

#4 Updated by Martynas Jusevicius 7 months ago

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().

#5 Updated by Martynas Jusevicius 7 months ago

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 :)

#6 Updated by Michael Kay 7 months ago

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

#7 Updated by Martin Honnen 7 months ago

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?

#8 Updated by Debbie Lockett 6 months ago

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.

#9 Updated by Martynas Jusevicius 6 months ago

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

#10 Updated by Debbie Lockett 6 months ago

  • Category set to XSLT Conformance
  • Status changed from New to In Progress
  • Assignee set to Debbie Lockett

Selenium test iss5036 added to our test suite (based on Martin's sample test).

#11 Updated by Debbie Lockett 5 months ago

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

Please register to edit this issue

Also available in: Atom PDF Tracking page