Bug #3423
closedIncorrect binding to modes by name
100%
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.
Updated by Michael Kay over 7 years ago
- 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.
Updated by John Lumley over 7 years ago
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.
Updated by John Lumley over 7 years ago
- Status changed from In Progress to Resolved
Can confirm that the dynamic evaluation no longer needs context.fixed.userFunctions
nor context.fixed.globalVars
Updated by Michael Kay over 7 years ago
I have dropped context.fixed.userFunctions and have changed the implementation of function-available() to work without it.
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