Saxon

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.

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.