Project

Profile

Help

Bug #6140

closed

Add SaxonJS 3.1 extension functions in Saxon 12.3

Added by Octavian Nadolu 11 months ago. Updated 7 months ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2023-07-27
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
12, trunk
Fix Committed on Branch:
12, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

Description

Hello,

I try to add the SaxonJS functions in the configuration extension library list using the code below. When I try to validate an XSL that uses the SaxonJS functions it complains that this are not recognized. Do you have any suggestions?

 if (configuration instanceof ProfessionalConfiguration) {
      ProfessionalConfiguration pConfiguration = (ProfessionalConfiguration) configuration;
      // Add SaxonJS 3.1 extension functions
      pConfiguration.getBuiltInExtensionLibraryList(31).addFunctionLibrary(IXSLFunctionSet.getInstance());
  
      //Register extension instructions
      pConfiguration.setExtensionElementCreator(
          NamespaceUri.of("http://saxonica.com/ns/interactiveXSLT"), IXSLElementFactory.FACTORY);
    }
Actions #1

Updated by Norm Tovey-Walsh 7 months ago

Hello, Octavian. Sorry for the delay in getting to this. I've created a unit test that reproduces the bug. It seems that the function library used by the stylesheet doesn't always inherit (any? all?) of the libraries defined in the configuration.

Actions #2

Updated by Michael Kay 7 months ago

It appears to work if you set the parameter on getBuiltInExtensionLibraryList(31) to 30 rather than 31 - specifically, the XSLT version number. This isn't documented, and I'm not sure why it works this way, but for the time being, it's a workaround.

Actions #3

Updated by Michael Kay 7 months ago

The change to make the builtInExtensionLibrary versioned was introduced on the 12.x branch (commit dated 24/11/2022) and it appears the thinking was to enable it to be different for 40 -- though I'm unclear as to exactly why. I think it would probably make sense if we only have two versions, 31 and 40.

Actions #4

Updated by Michael Kay 7 months ago

The basic reason for introducing the version dependency is that the array and map function sets vary between 3.1 and 4.0, and these form part of the standard "BuiltinExtensionLibraryList". We could in principle also support a 3.0 version, but we don't.

Actions #5

Updated by Michael Kay 7 months ago

  • Tracker changed from Support to Bug
  • Status changed from New to Resolved
  • Assignee set to Michael Kay
  • Applies to branch 12, trunk added
  • Fix Committed on Branch 12, trunk added
  • Platforms .NET, Java added

I have added Javadoc comments to the method Configuration.getBuiltInExtensionLibraryList() to explain what it does and how the version number is used; and I have changed the code so that any version number other than 40 gives you the function library appropriate to XPath 3.1.

Actions #6

Updated by O'Neil Delpratt 7 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 12.4 added

Bug fix applied in the Saxon 12.4 maintenance release

Please register to edit this issue

Also available in: Atom PDF