Maintenance: Planio will be observing a scheduled maintenance window this Sunday, November 10, 2024 from 20:00 UTC until 21:00 UTC to perform important network maintenance in our primary data center. Your Planio account will be unavailable for a few minutes during this maintenance window.
Bug #3423
closed
Incorrect binding to modes by name
Category:
XSLT Conformance
Applies to JS Branch:
0.9, 1.0, Trunk
Fix Committed on JS Branch:
Trunk
Description
Test override-v-015 demonstrates a problem with the binding of modes by name.
The initial mode is found by searching all mode components to find the first with a matching name. This is incorrect: it should always find a mode in the top-level package. Fixed this by using the same logic for finding the initial mode as we currently use for the initial function and the initial template.
This demonstrates another issue (which may be symptom-free): the index of modes (by name) held in context.fixed.modes is wrong in principle, because there can be several modes (in different packages) with the same name.
The same is true of the other indexes in context.fixed, such as context.fixed.globalVars and context.fixed.userFunctions.
- Status changed from New to In Progress
- Applies to JS Branch 0.9, 1.0, Trunk added
- Fix Committed on JS Branch Trunk added
I have fixed the original issue with override-v-015 by changing the way the initial mode is found.
I have eliminated context.fixed.modes.
I have eliminated context.fixed.globalVars.
Changes committed on the 2.0 branch.
Leaving open: need to discuss with John if there are any complications in eliminating context.fixed.userFunctions.
At present I don't think the xsl:evaluate
code uses context.fixed.userFunctions
in the compiliation phase - signatures are determined by searching a mapping of name->component,
in three distinct categories: "@function@", "@globalVariable@" and "@globalParam@" that has been generated from context.fixed.components.
This suggests that context-fixed.userFunctions
might be redundant for compilation and evaluation, since ufCall
at runtime also searches for components. I'll check this tomorrow. I haven't yet checked this in a situation where there are multiple packages.
There are a very few points in the XPath code that reference context.fixed.globalVars
but I think they are now redundant - will check.
- Status changed from In Progress to Resolved
Can confirm that the dynamic evaluation no longer needs context.fixed.userFunctions
nor context.fixed.globalVars
I have dropped context.fixed.userFunctions and have changed the implementation of function-available() to work without it.
- 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
- Category set to XSLT Conformance
Please register to edit this issue
Also available in: Atom
PDF
Tracking page