Project

Profile

Help

Bug #4549

closed

Saxon seems to use only a single index for multiple keys

Added by Jeremy Cronk almost 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2020-05-08
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 9.9
Fix Committed on Branch:
10, 9.9
Fixed in Maintenance Release:
Platforms:

Description

This isn't something I've been able to duplicate in anything but the original stylesheet, so I'm attaching the stylesheet, Main.xsl, along with its dependencies and an input file that shows the issue.

There's a bunch of indirect stuff happening via table lookups and function dispatch in this stylesheet, but when I try to replicate everything in a smaller stylesheet, everything seems to work correctly.

The specific issue here is that while there are a number of keys defined, when it hits the key-with-fallback function defined on line 2098, instead of using the specified table (which is coming from a table lookup itself), it seems to only use the key for coverage-option-codes-list, so in the output you get <LegalEntityCd>Incl</LegalEntityCd> on line 15, when it should be "IN", and same for BillingMethodCd on line 25 ("P" instead of "CPB"), etc. This only seems to happen in Saxon 9.9, and in Saxon 9.8, we get the correct lookup values returned.

My initial workaround was to use saxon:key-map() and add saxon:range-key="yes" to the key declarations. This causes the correct behavior in Saxon 9.9.1.7 but in Saxon 9.9.1.5, it raises an internal error.

With the attached version of the stylesheet, I've also tried to use xsl:message to check the values of the variables, params, and the result of the call to key() in the key-with-fallback function, but as soon as I do this, everything works properly.

I haven't been able to isolate a specific trigger for this, unfortunately, but I was thinking some kind of caching issue was happening, and on the mailing list you mentioned that the behavior points to an issue happening during optimization. I haven't had the opportunity to try with and without optimization, however.


Files

CodeLookup.xml (278 KB) CodeLookup.xml Jeremy Cronk, 2020-05-08 19:02
DataElements.xml (93.2 KB) DataElements.xml Jeremy Cronk, 2020-05-08 19:02
FormattingFunctions.xsl (11.4 KB) FormattingFunctions.xsl Jeremy Cronk, 2020-05-08 19:02
Main.xsl (134 KB) Main.xsl Jeremy Cronk, 2020-05-08 19:02
AL3DataDictionary.xml (1.27 MB) AL3DataDictionary.xml Jeremy Cronk, 2020-05-08 19:02
input.xml (1.83 KB) input.xml Jeremy Cronk, 2020-05-08 19:03

Please register to edit this issue

Also available in: Atom PDF