Bug #5099
closedValidator appears to ignore .setUseXsiSchemaLocation(false)
100%
Description
See s9apitest.TestValidator.testIgnoreSchemaLocationHints
on both the Saxon 10 and main branches.
Updated by Michael Kay over 2 years ago
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).
Updated by Michael Kay over 2 years ago
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.
Updated by Michael Kay over 2 years ago
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
.
Updated by Michael Kay over 2 years ago
- Category set to Schema-Aware processing
- Status changed from New to In Progress
- Assignee set to Michael Kay
- Priority changed from Low to Normal
We can fix the issue of having two validators in tandem by changing line 611 of SchemaValidatorImpl to
Sender.send(source, receiver, new ParseOptions());
that is, creating a new ParseOptions
object (with no validation request).
This would seem a slightly scary change. The other unit tests are all OK, but further testing is needed.
Updated by Michael Kay over 2 years ago
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.
Updated by Michael Kay over 2 years ago
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.
Updated by Michael Kay over 2 years ago
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.
Updated by Michael Kay over 2 years ago
- Status changed from In Progress to Resolved
- Applies to branch 10, trunk added
- Fix Committed on Branch 10, trunk added
I've added unit tests for the namespace case as well as the no-namespace case.
Summary of problems fixed:
(a) SchemaValidator.useXsiSchemaLocation is ignored
(b) On the 10 branch, two validators are added to the pipeline, operating in tandem.
(c) The base URI used for resolving location hints in xsi:schemaLocation and xsl:noNamespaceSchemaLocation is incorrect.
Updated by Michael Kay over 2 years ago
Ported the tests over to Saxon-CS and confirmed the fix works there.
Updated by Debbie Lockett about 2 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.7 added
Bug fix applied in the Saxon 10.7 maintenance release.
Please register to edit this issue