Bug #3678
closed
Configuration.buildDocumentTree() does not use local copies of W3C entity files
Applies to branch:
9.8, trunk
Fix Committed on Branch:
9.8, trunk
Fixed in Maintenance Release:
Description
Saxon is supposed to use its own local copies of well-known DTDs and similar resources, because the W3C server imposes a heavy delay on serving these files. This is not happening when a document is built using Configuration.buildDocumentTree().
Unit test testXQueryNative.testLocalW3CDTDaccess() has been created to demonstrate the problem.
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.
- Status changed from New to Resolved
- Applies to branch 9.8, trunk added
- Fix Committed on Branch 9.8, trunk added
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.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.10 added
Bug fix applied in the Saxon 9.8.0.10 maintenance release.
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.
Please register to edit this issue
Also available in: Atom
PDF