Project

Profile

Help

Maintenance: Planio will be observing a scheduled maintenance window this Tuesday, November 5, 2024 from 03:00 UTC until 06:30 UTC to perform urgent network maintenance in our primary data center. Your Planio account will be unavailable during this maintenance window.

Bug #3423

closed

Incorrect binding to modes by name

Added by Michael Kay about 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
XSLT Conformance
Sprint/Milestone:
-
Start date:
2017-09-02
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
0.9, 1.0, Trunk
Fix Committed on JS Branch:
Trunk
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

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.

Actions #1

Updated by Michael Kay about 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.

Actions #2

Updated by John Lumley about 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.

Actions #3

Updated by John Lumley about 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

Actions #4

Updated by Michael Kay about 7 years ago

I have dropped context.fixed.userFunctions and have changed the implementation of function-available() to work without it.

Actions #5

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
Actions #6

Updated by Debbie Lockett over 4 years ago

  • Category set to XSLT Conformance

Please register to edit this issue

Also available in: Atom PDF Tracking page