Project

Profile

Help

Actions
Send by e-mail Copy link

Bug #6140

closed

Add SaxonJS 3.1 extension functions in Saxon 12.3

Added by Octavian Nadolu over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Low
Assignee:
Michael Kay
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:
12.4
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
Copy link
 #1

Updated by Norm Tovey-Walsh about 1 year 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
Copy link
 #2

Updated by Michael Kay about 1 year 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
Copy link
 #3

Updated by Michael Kay about 1 year 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
Copy link
 #4

Updated by Michael Kay about 1 year 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
Copy link
 #5

Updated by Michael Kay about 1 year 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
Copy link
 #6

Updated by O'Neil Delpratt about 1 year 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

Actions
Send by e-mail Copy link

Also available in: Atom PDF