Project

Profile

Help

Bug #4518

Saxon XSD 1.1 using Saxon EE : use of xs:override

Added by Octavian Nadolu 4 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Schema conformance
Sprint/Milestone:
-
Start date:
2020-04-14
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 9.9
Fix Committed on Branch:
10, 9.9
Fixed in Maintenance Release:

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)
conference-calendar.xsd (622 Bytes) conference-calendar.xsd Octavian Nadolu, 2020-04-14 09:30
office-calendar.xsd (726 Bytes) office-calendar.xsd Octavian Nadolu, 2020-04-14 09:30

History

#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.)

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?

#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.

#4 Updated by O'Neil Delpratt 3 months ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.1 added

Bug fix committed in the Saxon 10.1 maintenance release.

Please register to edit this issue

Also available in: Atom PDF