Summary: test "s3_4_2_4ii08s" of set "defaultAttributesApply"
Product: XML Schema Test Suite
Component: IBM tests
AssignedTo: [hidden email] ReportedBy: [hidden email] QAContact: [hidden email]
In my opinion test "s3_4_2_4ii08s" and "s3_4_2_4ii10s" of set
"defaultAttributesApply" should be invalid (or their second ts:schemaDocument
element should be removed).
Both of them have two ts:schemaDocument elements. The schema referenced by the
second one is overridden by an xs:override in the first one. So listing both of
them as ts:schemaDocument in the ts:schemaTest element causes duplicate
components in the resulting schema (the overridden component clashes with the
original "imported" by the ts:schemaDocument element).
See the last note in http://www.w3.org/TR/xmlschema11-1/#src-override: "Note: It is a consequence of the semantics of inclusion, as defined in
Inclusion Constraints and Semantics (§4.2.3) (in particular clause 3.1.2 and
clause 3.2.2); redefinition, as defined in Including modified component
definitions (<redefine>) (§4.2.4); import, as defined in References to schema
components across namespaces (<import>) (§4.2.6); and overriding, as defined in
this section, that if the same schema document is both (a) included, imported,
or redefined, and (b) non-vacuously overridden, or if the same schema document
overridden twice in different ways, then the resulting schema will have
duplicate and conflicting versions of some components and will not be
conforming, just as if two different schema documents had been included, with
different declarations for the same ·named· components."
What |Removed |Added
CC| |[hidden email]
--- Comment #1 from Michael Kay <[hidden email]> 2012-06-29 16:01:01 UTC ---
The WG recognizes this problem with the test set metadata (and has done so for
a while); this bug report may spur us to make the effort to resolve the
For what it's worth, this is what the Saxon test driver does: It loads the
first schema document listed. Then for each subsequent schema document in turn,
it reads the targetNamespace of the schema document, and then loads the schema
in this schema document if and only if the targetNamespace is "new", that is,
if the loaded schema does not already contain components for this namespace.
This is a very pragmatic approach, and not justified by anything in the test
specs, but it works for me.