XPath 3.0 Functions
Added by Dieter Stüken almost 12 years ago
Hello,
I want to perform some geometric calculations and found the functions I need with XPath 3.0 [[http://www.w3.org/TR/xpath-functions-30/#trigonometry]]. Saxon 9.4 provides these functions already but they are part of SaxonPE. Since we don't have an PE licence (until now) I can't use them instantaneously. But as I use the saxon API directly, I'm able to provide my own implementation of those functions using ExtensionFunctionDefinitions.
I'm willing to provide my version, but I don't see how to contribute, since the public development via Sourceforge has been discontinued. Are there any interests to see those functions within HE anyway?
An other question is, how to integrate such a saxon extension. Currently I just configure net.sf.saxon.Configuration explicitly. As an alternative I might extend net.sf.saxon.Configuration like com.saxonica.config.ProfessionalConfiguration does and add my own configuration capabilities. But I don't know, if this is intended/wanted as this would not cooperate well with the PE/EE extensions.
I just discovered net.sf.saxon.trans.DynamicLoader, but I still have to understand how to use it. Since Java 1.6 I'm using [[http://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html]], which is very handy...
let me know.
Dieter.
Replies (2)
RE: XPath 3.0 Functions
-
Added by Michael Kay almost 12 years ago
There are a couple of good points here.
Firstly, there's a point about community development of Saxon. I'm afraid we've never been very good at managing this. There have been contributions in the past via Sourceforge, but very often they have lacked basic things like documentation and test cases (sometimes people have even submitted code that is obviously untested); and for our part we haven't been good at telling people what is needed in terms of documentation and test cases. Also for a few years now, before accepting a contribution into the product that we distribute, we have asked people to sign an agreement to make the intellectual property position quite clear and to be sure that their employers have permitted the contribution, and a lot of people find it easier to write a few lines of code than to sign a legal document making those lines of code publicly available. We should do better at this; but of course, we aren't strongly motivated to do so when the nature of the contribution replicates something that we've decided to make available only in the commercial product. (Not that we see a math library as high business value; it's just that our current policy is that all Saxon extensions and all 3.0 features are in PE only).
Secondly, there's the point about how to configure these. It' hard to make this easy because there are so many different class loading environments in use: doing something that works in Eclipse etc can be a nightmare. If you want the extensions to be usable from the command line it's probably best to provide an Initializer (net.sf.saxon.lib.Initializer). If lots of people start using this mechanism then we will probably have to dream up a way of chaining them together.
RE: XPath 3.0 Functions
-
Added by Dieter Stüken almost 12 years ago
so, instead of extending @Configuration@ itself I simply supply an Initializer. If don't have a command line I just call @(my)initializer.initialize(config)@ explicitly.
I'll try to combine it with a @ServiceLoader@ to apply multiple initializers: The main Initializer (loaded manually either by command line option or explicitly) discovers additional initializers using @ServiceLoader.load(net.sf.saxon.lib.Initializer.class)@ and applies them all.
Advantage:
- extensions may be deployed by just dropping a jar providing appropriate META-INF/services.
Disadvantage:
- there is no way to control the order of initializations.
But each Initializer is free to play the same game again and to load specialized extensions concerning its own domain.
Dieter.
Please register to reply