Saxon

It's legitimate for the ApiProvider to be null. Saxon itself appears to no longer use this property. I think it was provided primarily for extension functions, for example if we supply a node to an extension function then the extension function might want to create a serializer, and this property enables it to get back to the originating s9api Processor so that it can do so. It's a rather pragmatic kludge anyway, since it's quite possible, for example, for a JAXP TransformerFactory and an XQJ DataSource to share the same Configuration, in which case there's no way the Configuration can remember both of them.

I think the fact that new Processor(Configuration config) doesn't call config.setProcessor() is deliberate. The thinking is that this Processor isn't responsible for creating this Configuration; it doesn't own it, and shouldn't claim ownership of it.

Michael Kay wrote:

I think it was provided primarily for extension functions, for example if we supply a node to an extension function then the extension function might want to create a serializer, and this property enables it to get back to the originating s9api Processor so that it can do so.

Yes, someone complain about this very situation, in an extension function. Is there another recommended way to get access to such an API from an extension function?

well, you can always supply data directly from the calling application to the class implementing the extension function before the Saxon transformation starts...