Bug #3424
closedTwo keys with same name in different packages
100%
Description
The data structure used to locate the index corresponding to a particular key name assumes that there cannot be two different key definitions with the same name applicable to a document.
Example test case that fails as a result: use-package-102.
There are two calls on key() here which correctly bind to different key definitions. However, when the second key definition is used, the code wrongly assumes that an index for that key definition already exists, when actually it is an index for a different key definition with the same name (in a different package).
Updated by Michael Kay about 7 years ago
- Subject changed from Incorrect binding to keys and decimal formats with multiple packages to Two keys with same name in different packages
- Description updated (diff)
Updated by Michael Kay about 7 years ago
- Status changed from New to In Progress
I have resolved this particular test case by introducing logic to allocate a random unique ID to each key definition on initialisation of the transformation.
This also solves another problem, namely that indexes created for a source document during one transformation might be reused by another transformation even though stylesheet parameters used within the key definition are different, meaning that old index is no longer applicable.
However, I have done it by writing additional attributes to the SEF DOM, which is incorrect, because two concurrent transformations might be using the same SEF DOM.
The current patch also causes regression to one test case in the "key" test set, which needs investigation.
Updated by Michael Kay about 7 years ago
- Status changed from In Progress to Resolved
- Fix Committed on JS Branch Trunk added
I have now amended the solution so the dynamically-allocated unique ID of an index is held locally (in context data) rather than by modifying the SEF DOM. Committing this solution.
Updated by Debbie Lockett over 4 years ago
- Description updated (diff)
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in JS Release set to Saxon-JS 2.0
Please register to edit this issue
Also available in: Atom PDF Tracking page