Feature #5755
open
Wouldn't it be nice to have an Package Resolver?
Category:
XSLT 3.0 packages
Fixed in Maintenance Release:
Description
The general idea:
Saxon should have a new configuration option where the user can provide a Java class implementing a specific interface. The class should work similar to the URIResolver, just for packages. It receives a package name and a requested version info like it was specified in the <xsl:use-package> and returns the javax.xml.transform.Source of the package file or null if the package is not available. Any time Saxon compiles a stylesheet containing an <xsl:use-package> declaration it asks at first the Pakage Resolver for the resource. If it returns null it uses the current logic to get it.
What is the benefit?
- You could implement a repository based pull mechanism for XSLT packages .In my mind, it's something like Maven already does with its dependency concept. Companies could maintain internal repositories or even an "XSLT central" could be come real.
- You could make lookups for packages based on common patterns. For instance I developed an XSLT Package Handler which works with the generic initializer option and collects all packages which can be found in the classpath. This would be much more elegant, if it would not use the very generic intializer interface and if it would have a pull mechanism.
What do you think?
There's certainly scope for improvement in the facilities for package resolution, and there are ideas here that are worth considering.
Are you aware of what you can do with configuration files - see https://www.saxonica.com/documentation11/index.html#!configuration/configuration-file/config-xsltPackages - and have you found shortcomings in the capabilities there?
Or to manage it programmatically, you can create an XsltPackage object and register it with the XsltCompiler.
I'm interested to know more about the limitations of these approaches before embarking on something more ambitious.
Hi Michael,
thanks for the fast response.
Are you aware of what you can do with configuration files - see https://www.saxonica.com/documentation11/index.html#!configuration/configuration-file/config-xsltPackages - and have you found shortcomings in the capabilities there?
I described some of concerns about configuring packages using the config file here.
[...]
And that is where the problems begin if I try to provide the packages as Maven dependencies:
- I have to declare in the Saxon configuration file and in the Maven pom.xml the dependencies. This is duplicate code!
- I have to know the full path to my package XSLT file. As this is wrapped by a jar file I have to know the path inside the jar file. This is handled by my dependency project and should not be part of the using project. This is not declarative!
- The path resolution of the locations is restricted. The URLs are not resolved by the given catalog file. I can not use the catalogBuilder-plugin to run my source code without creating a full package. This is not handy!
But also beside of Maven I don't like this configuration level, for the following reasons:
- In my projects the config file is part of the project source code. I don't see the benefit for writing the path to the package resource into the config file instead of writing it into the XSLT stylesheet (e.g. by an
xsl:import).
- At least in my tests the resolving against the used catalog didn't worked for the URLs pointing to packages in the config file (should it?). If so, it is even worse than using
xsl:import.
- XSLT 3.0 allows wildcards or ranges in the
package-version attribute. For me this is an indication that there should be a pull mechanism. Otherwise it does not make sense to me.
Or to manage it programmatically, you can create an XsltPackage object and register it with the XsltCompiler.
This is new to me. Are you pointing at this? I have to check, but for the first glance it does not seem to be possible to implement a pull mechanism with it, is it?
And the positive view: For me it is a logical step. You have resolver or similar classes for URLs, Collections, Unparsed Text Resources. Why not for XSLT Packages?
Please register to edit this issue
Also available in: Atom
PDF
.