Saxon

The problem is that

protected ConfigurationReader makeConfigurationReader() {
        return new ConfigurationReader();
    }

at Configuration#472 has an override in EnterpriseConfiguration to create a ConfigurationReaderEE, but it has no override in ProfessionalConfiguration to create a ConfigurationReaderPE.

Is this fix in saxon-pe-10.3?

It looks as if this fix wasn't committed on the 10.x branch, due to a mix up when we reorganised the repository structure (but there hasn't been a public maintenance release since then anyway). It's a simple fix and I will apply it now so it comes out in the next maintenance release.

Thanks @Michael Kay for digging into this. Is there an ETA on that maintainance release? Or would I be able to use a patched version somehow till the new release goes live?

It turns out to be a bit more complicated that I thought, which might be why the history is also a bit confused. At present, on the 10.x branch,

• When running from the command line, net.sf.saxon.Transform calls Configuration.readConfiguration(new StreamSource(configFile)); which is a static method (the same for all editions) that does

        Configuration tempConfig = newConfiguration();
        return tempConfig.readConfigurationFile(source);

The kind of configuration held in tempConfig depends solely on what JAR file is on the classpath. The readConfigurationFile(source) method instantiates a ConfigurationReader in HE, and a ConfigurationReaderPE in EE (sic) - there is no separate ConfigurationReaderEE. There should be an override of the method in PE.

There's a separate two-argument method Configuration readConfigurationFile(Source source, Configuration baseConfiguration). This exists only in HE, but it invokes makeConfigurationReader() which (correctly) has separate versions in HE and PE. But this version is used only when invocation is via the fn:transform() function.

When a configuration file is specified using the JAXP TranformerFactory interface, each TransformerFactory instantiates the correct kind of ConfigurationReader and the logic here appears to be correct.

When a configuration file is specified using the s9api method new Processor(Source), we invoke Configuration.readConfiguration(source) which appears to follow the same (incorrect) path as command-line invocation.

A workaround is to set the extension element factory programmatically rather than via a configuration file, using the method ProfessionalConfiguration.setExtensionElementNamespace(). If running from the command line, you can do this in a -init hook, or by subclassing net.sf.saxon.Transform and overriding the initializeConfiguration() method.

Confirmed that the problem was already fixed on the development branch.

What are the next steps on this?

Hi, any chance of backporting this to 9.9?

I need to call transformation that uses extension elements from exist-db and exist-db still uses Saxon 9.9.