Bug #3423: Incorrect binding to modes by name - SaxonJS - Saxonica Developer Community

Actions

Send by e-mail Copy link

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:

Michael Kay

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:

Saxon-JS 2.0

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

Copy link

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

Copy link

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

Copy link