Bug #4518
closedSaxon XSD 1.1 using Saxon EE : use of xs:override
100%
Description
If I validate the attached file "conference-calendar.xsd" with Saxon EE 9.9.1.7 (also with Saxon EE 9.9.1.5) I get the following error: "xs:schema must be the outermost element in a schema document"
This is the stack trace of the error:
; SystemID: file:///D:/Programs/Oxygen%20XML%20Editor%2022.0/override.xsl; Line#: -1; Column#: -1
net.sf.saxon.type.SchemaException: <xs:schema> must be the outermost element in a schema document
at com.saxonica.ee.schema.sdoc.SchemaElement.error(SchemaElement.java:396)
at com.saxonica.ee.schema.sdoc.XSDSchema.validate(XSDSchema.java:392)
at com.saxonica.ee.schema.sdoc.SchemaElement.validateSubtree(SchemaElement.java:192)
at com.saxonica.ee.schema.sdoc.XSDOverride.prepareAttributes(XSDOverride.java:131)
at com.saxonica.ee.schema.sdoc.SchemaElement.processAllAttributes(SchemaElement.java:131)
at com.saxonica.ee.schema.sdoc.SchemaElement.processAllAttributes(SchemaElement.java:136)
at com.saxonica.ee.schema.sdoc.SchemaReader.read(SchemaReader.java:167)
at com.saxonica.config.EnterpriseConfiguration.addSchemaSource(EnterpriseConfiguration.java:676)
at com.saxonica.ee.jaxp.SchemaFactoryImpl.newSchema(SchemaFactoryImpl.java:271)
at javax.xml.validation.SchemaFactory.newSchema(Unknown Source)
Files
Updated by Michael Kay over 4 years ago
Added this as test case Saxonica/Override/over031 to the XSD test suite.
Failure reproduced under 9.9, although it is produced as a "recoverable error" with no stack trace.
In fact the same warning is produced for all the xs:override tests; but it has gone unnoticed because test is reported as successful.
Note also: with -scm:/Users/mike/repo/samples/scm/scmschema.scm
on the command line to invoke the XSD test suite driver, I'm getting an error that the schema for SCM doesn't allow the @dmk attribute (which is present because of the license key I am using).
Updated by Michael Kay over 4 years ago
The actual condition triggering the error message is that the xs:schema
element (in the output of the override.xsl transformation) is parentless. The error would also be produced if the parent of the xs:schema
element is another element (rather than a document node).
In both cases, the error seems inappropriate. There's nothing in the XSD spec that says an xs:schema element can't be parentless, or that it can't be embedded in another XML document. In fact XSLT explicitly allows xs:schema
to have xsl:import-schema
as a parent element. (Presumably this works in Saxon because we copy an inline schema before processing it.)
The override.xsl
transformation is being performed by SchemaDocumentTransformer.transform()
, which quite legitimately constructs a tree that is rooted at the (parentless) xs:schema element.
I think the error check at the start of XSDSchema.validate()
should probably be removed (the validate
method should follow the principle that validity depends on your content but not on your context); the question is, what are the possible consequences of doing so?
Updated by Michael Kay over 4 years ago
- Category set to Schema conformance
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 10, 9.9 added
- Fix Committed on Branch 10, 9.9 added
Removing the check does not cause any regression in the W3C XSD tests, so I've decided to apply this change.
Updated by O'Neil Delpratt over 4 years ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.1 added
Bug fix committed in the Saxon 10.1 maintenance release.
Updated by O'Neil Delpratt about 4 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 10.2, 9.9.1.8 added
- Fixed in Maintenance Release deleted (
10.1)
Bug fix applied on the Saxon 9.9.1.8 maintenance release.
Please register to edit this issue