Saxon

It looks like the option validator.setUseXsiSchemaLocation(false) is only effective when the SchemaValidator is used as a Destination: added another JUnit test testIgnoreSchemaLocationHintsWithValidatorDestination to demonstrate that (it passes).

The variable XSIAttributeHandler.useXsiSchemaLocation appears to be written but never read, which isn't encouraging.... the conditional based on this variable seems to have got lost in the transition from 9.9 to 10 with the refactoring of the Receiver interface to pass attributes with the startElement() event.

Added the condition on useXsiSchemaLocation in XSIAttributeHandler.startElement() and the test case now passes.

Except that it's reporting the error twice: why?

We actually seem to be running the document through two schema validators in tandem: the stack trace contains two instances of DocumentValidator.

The first is allocated by SchemaValidatorImpl.validate() -> getReceiver() -> EnterpriseConfiguration.getDocumentValidator()#1399.

The second is allocated by SchemaValidatorImpl.validate() -> Sender.send() -> EnterpriseConfiguration.getDocumentValidator()#1399.

I've run this past all the s9api and JAXP unit tests and through the qt3 and xslt3 test suites, with no sign of adverse effects.

Now investigating why the second unit test, testIgnoreSchemaLocationHintsWithValidatorDestination, appears to work without the patch. Exploring this on the 11 branch where the patch is not yet applied.

It seems that it's trying to load the schema (document.xsd) but failing because of a base URI issue.

XSIAttributeHandler.processXsiNoNamespaceSchemaLocation(Location locationId, String value) is calling getSystemId() to get the base URI for resolving the schemaLocation attribute. getSystemId() returns null, so ResolveURI resolves against the current directory.

We should be resolving against locationId.getSystemId() to reflect the base URI of the element containing the xsi:schemaLocation attribute.

On the 11 branch, the creation of two validators in tandem has been fixed "by accident" as a result of the rewrite of Sender.send() to use common code for all implementations of the new ActiveSource interface. As a result of this change, send() creates a validator using the existing makeValidator() method, which checks whether the supplied Receiver is already a DocumentValidator, and does nothing if this is the case.

However, setting the send() request parser options so that we don't request a second validation when we know we don't need it seems a more robust solution.

Ported the tests over to Saxon-CS and confirmed the fix works there.