Project

Profile

Help

Feature #3198

closed

Specifing XSLT packages in the Saxon configuration file

Added by Alex Jitianu about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2017-04-11
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

Hello,

As far as I can tell, it is not possible to specify inside a Saxon configuration file one or more xsl:package to be used by the xsl:use-package instructions during the transformation (an equivalent to the -pack command line option).

Some background of what we try to achieve. In Oxygen XML Editor we are using Saxon through its JAXP implementations and our users can't validate XSLTs that are based on *xsl:use-packag*e. So we need a mechanism to configure Saxon. Other than the -pack argument, as far as I can tell, the only possibility is to use XsltCompiler.importPackage() but we don't have access to this API when using the JAXP implementations (the compiler is used somewhere inside net.sf.saxon.jaxp.SaxonTransformerFactory.newTemplates(Source)).

I'm looking forward to any advice that you might have in this regard.

Thank you,

Alex

Actions #1

Updated by Alex Jitianu about 7 years ago

By the way, the user that reported this issue noticed that xsl:use-package/@name is defined as URI. So he mapped that URI in a catalog file and expected Saxon to use that mapping. Perhaps that is also a viable approach?

Actions #2

Updated by Michael Kay about 7 years ago

  • Assignee set to Michael Kay

Yes, we definitely need to improve the mechanisms for specifying the mapping from package names and versions to actual locations. I guess that the JAXP case also needs to be taken into account - to be honest, I keep thinking that JAXP isn't up to the task any more, and then we stretch what it can do just a little bit further.

Part of the issue is that this isn't just a name->address mapping issue, we also need a good way of handling package versions.

I'll give it some (more) thought.

Actions #3

Updated by Michael Kay almost 7 years ago

  • Status changed from New to In Progress
  • Priority changed from Low to Normal

Have implemented this on the 9.8 branch. Leaving the issue open until all development and testing is complete.

Actions #4

Updated by Michael Kay almost 7 years ago

  • Status changed from In Progress to Resolved

This feature has now been implemented for the Saxon 9.8 release.

Actions #5

Updated by Michael Kay almost 7 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF