Saxon XSD 1.1 using Saxon EE : use of xs:override
If I validate the attached file "conference-calendar.xsd" with Saxon EE 184.108.40.206 (also with Saxon EE 220.127.116.11) 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)
#1 Updated by Michael Kay 4 months 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).
#2 Updated by Michael Kay 4 months 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.)
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?
#3 Updated by Michael Kay 4 months 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.
Please register to edit this issue