Saxon

When Query is run from the command line, it uses the s9api DocumentBuilder, and this initializes the parseOptions using Configuration.getParseOptions(), which by default includes the StandardEntityResolver that fetches local resources. The s9api DocumentBuilder then calls the two-argument form of Configuration.buildDocumentTree(), supplying these parse options.

The single-argument form of Configuration.buildDocumentTree() is not using the default parse options set up in the Configuration. This doesn't seem to match what the Javadoc says "Build a document tree, using options set on this Configuration and on the supplied source

object." Nevertheless, changing the code to match the documentation here could be risky and needs careful testing.

I decided to make this change: the single argument version of Configuration.buildDocumentTree() now picks up the defaultParseOptions from the Configuration (if the source is not an AugmentedSource).

I've run the relevant sections of the unit tests and there appear to be no adverse consequences, though it's definitely a fix that could change the behaviour of user applications.

I have made some further changes to Configuration.buildDocumentTree(Source) on the development branch. It no longer calls resolveSource() itself, but rather leaves that to the call on buildDocumentTree(Source, ParseOptions) which follows. There might be a slight change in behaviour for the case where a user-supplied SourceResolver returns an AugmentedSource, but I think we still handle that obscure case in a reasonable way.