Saxon

Two questions:

(a) Are you using the XML parser built in to the JDK, or some other parser (such as Apache Xerces)

(b) If the JDK parser, which JDK version?

This is all about persuading Saxon to configure the XML parser on your behalf, which is tricky because different parsers don't all behave in the same way.

The other point I would make here is that we will never guarantee 100% compatibility of Saxon's JAXP TransformerFactory implementation with the one in the JDK. There are a number of reasons:

(a) the JAXP interfaces are under-specified

(b) the JAXP interface specifications have changed over the years (not the formal interfaces, but details such as requiring particular configuration properties to be recognized) and we have no input to these changes

(c) there's no interoperability test suite for JAXP

(d) the JDK implementation is XSLT 1.0 with vendor extensions that are permitted but not required for XSLT conformance

Therefore it's unwise to put an application into production that relies solely on JAXP interfaces, and expect it to work whatever TransformerFactory it finds lying around on the classpath. You need test your application against every JAXP TransformerFactory that you intend to support.

I use the built in parsers of JDK11. Without the Saxon library TransformerFactory.newInstance returns com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl (which is the same as newDefaultInstance).

If Saxon can not guarantee the compatibility wouldn't it be even more important to have an easy way to opt out from Saxon being used everywhere newInstance is used?

If you could provide 2 Saxon dependencies a user could choose:

• I want Saxon and use it everywhere (via newInstance) or
• I want Saxon but I define explicitely where I want to use it (for example via BasicTransformerFactory)

If Saxon can not guarantee the compatibility wouldn't it be even more important to have an easy way to opt out from Saxon being used everywhere newInstance is used?

It would be great if we could do that but we can't: the JAXP instantiation mechanism isn't under our control. The only way we can opt out is by not including the relevant entry in the JAR manifest, which would stop the mechanism working for everybody. That's what we chose to do with XPath - we no longer register as an XPath service provider, and you only get Saxon if you explicitly request it. But we decided it would be too disruptive to do the same on the XSLT side.

Bug #4234 was concerned with the JAXP validation interface, not with the transformation interface. The fix for that bug caused the three properties

XMLConstants.FEATURE_SECURE_PROCESSING
XMLConstants.ACCESS_EXTERNAL_DTD
XMLConstants.ACCESS_EXTERNAL_SCHEMA

to be recognised on the validation API, but it made no changes to the transformation API, and did not cause XMLConstants.ACCESS_EXTERNAL_STYLESHEET to be recognised.

I propose to fix this so that the transformation interface conforms with JAXP 1.5. Note however that this will not fix the underlying problem, which is that a transformation that requires Xalan should explicitly load Xalan, rather than using the JAXP loading mechanism indiscriminantly. There may well be other aspects of your transformation that make it dependent on Xalan (or on XSLT 1.0).

Also note, the fix for #4234 didn't actually result in the ACCESS_EXTERNAL_SCHEMA property being recognized on the schema validation interface, because of difficulties interpreting exactly what the JAXP specification was supposed to mean.

Discussed at team meeting. We decided that it might make sense to apply these properties before calling the relevant resolver, rather than leaving the resolver to make the decision. This would generalise more easily to different kinds of resource and resolver, especially resources not relevant to XSLT 1.0 processors, such as unparsed text and JSON resources.

I'm now implementing this.

The JAXP definition is hopelessly underspecified, even allowing for the fact that it assumes XSLT 1.0. For example, it doesn't say what happens if you call setAttribute() with one of these properties more than once: are they supposed to be cumulative? I'm assuming the last one wins. I'll attempt to respect the intent, rather than the detail.

ACCESS_EXTERNAL_DTD will be passed straight to the XML parser - which means it's ignored if the user supplies the parser, and is only effective if Saxon instantiates the parser itself.

ACCESS_EXTERNAL_STYLESHEET will map to the Saxon Configuration property Feature.ALLOWED_PROTOCOLS which will be changed to affect all resources fetched directly by Saxon (schemas, source documents, stylesheet modules, queries, JSON documents etc etc), and to kick in before calling any URI resolver. On the Validation APIs, ACCESS_EXTERNAL_SCHEMA will set the same Saxon Configuration property.

I decided to roll back on this, and go for a minimum change that fixes the bug.

In Saxon 10 we introduced a configuration property Feature.ALLOWED_PROTOCOLS which has the format of the JAXP constants such as ACCESS_EXTERNAL_STYLESHEET. If ACCESS_EXTERNAL_STYLESHEET is supplied on the TransformerFactory, I shall simply set ACCESS_EXTERNAL_STYLESHEET on the Configuration. This property is currently used by the "standard" resolvers (such as the standard URI resolvers, and can be overridden or ignored if a custom resolver is used.

The ACCESS_EXTERNAL_DTD property will be passed through to the XML parser in cases where Saxon instantiates the XML parser. It won't affect any user-supplied parser (e.g an XMLReader in a SAXSource).

Bug fix applied in the Saxon 10.3 maintenance release