W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures -- Review Version

...

4 Schemas and Namespaces: Access and Composition

This chapter defines the mechanisms by which this specification establishes the necessary precondition for ·assessment·, namely access to one or more schemas. This chapter also sets out in detail the relationship between schemas and namespaces, as well as mechanisms for modularization of schemas, including provision for incorporating definitions and declarations from one schema in another, possibly with modifications.

Conformance (§2.4) describes three levels of conformance for schema processors, and Schemas and Schema-validity Assessment (§5) provides a formal definition of ·assessment·. This section sets out in detail the 3-layer architecture implied by the three conformance levels. The layers are:

The ·assessment· core, relating schema components and instance information items;
Schema representation: the connections between XML representations and schema components, including the relationships between namespaces and schema components;
XSD web-interoperability guidelines: instance->schema and schema->schema connections for the WWW.

Layer 1 specifies the manner in which a schema composed of schema components can be applied to in the ·assessment· of an instance element information item. Layer 2 specifies the use of <schema> elements in XML documents as the standard XML representation for schema information in a broad range of computer systems and execution environments. To support interoperation over the World Wide Web in particular, layer 3 provides a set of conventions for schema reference on the Web. Additional details on each of the three layers is provided in the sections below.

...

4.2 Layer 2: Schema Documents, Namespaces and Composition

        4.2.1 Conditional inclusion
        4.2.2 Assembling a schema for a single target namespace from multiple schema definition documents (<include>)
        4.2.3 Including modified component definitions (<redefine>)
        4.2.4 Overriding component definitions (<override>)
        4.2.5 References to schema components across namespaces (<import>)
            4.2.5.1 Licensing References to Components Across Namespaces
            4.2.5.2 Providing Hints for Schema Document Locations

The sub-sections of Schema Component Details (§3) define an XML representation for type definitions and element declarations and so on, specifying their target namespace and collecting them into schema documents. The two following sections relate to assembling a complete schema for ·assessment· from multiple sources. They should not be understood as a form of text substitution, but rather as providing mechanisms for distributed definition of schema components, with appropriate schema-specific semantics.

Note: The core ·assessment· architecture requires that a complete schema with all the necessary declarations and definitions be available. This will sometimes involve resolving both instance → schema and schema-document → schema references. As observed earlier in Conformance (§2.4), the precise mechanisms for resolving such references are expected to evolve over time. In support of such evolution, this specification observes the design principle that references from one schema document to a schema use mechanisms that directly parallel those used to reference a schema from an instance document.

Note: In the sections below, "schemaLocation" really belongs at layer 3. For convenience, it is documented with the layer 2 mechanisms of import and include, with which it is closely associated.

...

4.2.2 Assembling a schema for a single target namespace from multiple schema definition documents (`<include>`)

Schema components for a single target namespace can be assembled from several ·schema documents·, that is several <schema> element information items:

XML Representation Summary: include Element Information Item

<include
  id = ID
  schemaLocation = anyURI
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</include>

A <schema> information item may contain any number of <include> elements. Their schemaLocation attributes, consisting of a URI reference, identify other ·schema documents·, that is <schema> information items.

The ·XSD schema· corresponding to <schema> contains not only the components corresponding to its definition and declaration [children], but also all the components of all the ·XSD schemas· corresponding to any <include>d schema documents. Such included schema documents must either (a) have the same targetNamespace as the <include>ing schema document, or (b) no targetNamespace at all, in which case the <include>d schema document is converted to the <include>ing schema document's targetNamespace.

Schema Representation Constraint: Inclusion Constraints and Semantics

In addition to the conditions imposed on <include> element information items by the schema for schema documents, all of the following also apply:

1 If the ·actual value· of the schemaLocation [attribute] successfully resolves one or more of the following is true:

1.1 It resolves to (a fragment of) a resource which is an XML document (of type application/xml or text/xml with an XML declaration for preference, but this is not required), which in turn corresponds to a <schema> element information item in a well-formed information set.

1.2 It resolves to a <schema> element information item in a well-formed information set.

In either case call the <include>d <schema> item D2 and the <include>ing item's parent <schema> item D1.

2 One of the following must be true:

2.1 D2 has a targetNamespace [attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace [attribute] of D1 (which must have such an [attribute]).

2.2 Neither D2 nor D1 have a targetNamespace [attribute].

2.3 D2 has no targetNamespace [attribute] (but D1 does).

3 The appropriate case among the following must be true:

3.1 If clause 2.1 or clause 2.2 above is satisfied, then all of the following are true:

3.1.1 D2 corresponds to a conforming schema (call it S2).

3.1.2 The schema corresponding to D1 includes not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of S2.

3.2 If clause 2.3 above is satisfied, then all of the following are true:

3.2.1 Let D2′ be a <schema> information item ↓identical to D2 except that it has a targetNamespace [attribute] whose value is the same as the ·actual value· of the targetNamespace [attribute] of D1;↓ ↓↓↑obtained by performing on D2 the transformation specified in Transformation for Chameleon Inclusion (§G.1);↑ D2′ corresponds to a conforming schema (call it S2).

↑

Note: The transformation in Transformation for Chameleon Inclusion (§G.1) (a) adds a targetNamespace [attribute] to D2, whose value is the same as that of the targetNamespace [attribute] of D1, and (b) updates all unqualified QName references so that their namespace names become the ·actual value· of the targetNamespace [attribute]. Implementations need not use the [XSLT 2.0] stylesheet given in Transformation for Chameleon Inclusion (§G.1), as long as the same result is produced.

↑

3.2.2 The schema corresponding to D1 includes not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of S2.

Note: The above rule applies recursively. For example, if A includes B and B includes C, where A has a targetNamespace [attribute], but neither B nor C does, then the effect is as if A included B' and B' included C', where B' and C' are identical to B and C respectively, except that they both have a targetNamespace [attribute] the same as A's.

Note: In this case, it is D2′, not D2, which is required by clause 3.2.1 to correspond to a conforming schema. In particular, it is not an error for D2 to fail to satisfy all of the constraints governing schema documents, while it is an error if D2′ fails to satisfy them.

Note: If D2 imports the target namespace of D1, then the effect of clause 3.2 will be to cause an error owing to the violation of clause 1 of Import Constraints and Semantics (§4.2.5.2) (which forbids a schema document to import its own target namespace). Other constraint violations may also be brought about; caution is advised.

It is not an error for the ·actual value· of the schemaLocation [attribute] to fail to resolve at all, in which case the corresponding inclusion must not be performed. It is an error for it to resolve but the rest of clause 1 above to fail to be satisfied. Failure to resolve is likely to cause less than complete ·assessment· outcomes, of course.

As discussed in Missing Sub-components (§5.3), ·QName·s in XML representations will sometimes fail to ·resolve·, rendering components incomplete and unusable because of missing subcomponents. During schema construction, implementations must retain ·QName· values for such references, in case an appropriately-named component becomes available to discharge the reference by the time it is actually needed. ·Absent· target ·namespace name·s of such as-yet unresolved reference ·QName·s in <include>d components must also be converted if clause 3.2 is satisfied.

Note: The above is carefully worded so that multiple <include>ing of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (§3.17.6.1), but applications are allowed, indeed encouraged, to avoid <include>ing the same schema document more than once to forestall the necessity of establishing identity component by component.

4.2.3 Including modified component definitions (`<redefine>`)

Note: The redefinition feature described in the remainder of this section is ·deprecated· and may be removed from future versions of this specification. Schema authors are encouraged to avoid its use in cases where interoperability or compatibility with later versions of this specification are important.

Editorial Note: Priority Feedback Request

The Working Group requests feedback from readers, schema authors, implementors, and other users of this specification as to the desirability of retaining, removing, deprecating, or not deprecating the use of <redefine>. Since the <override> facility provides similar functionality but does not require a restriction or extension relation between the new and the old definitions of redefined components, the Working Group is particularly interested in learning whether users of this specification find that requirement useful or not.

In order to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications. The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not.

XML Representation Summary: redefine Element Information Item

<redefine
  id = ID
  schemaLocation = anyURI
  {any attributes with non-schema namespace . . .}>
  Content: (annotation | (simpleType | complexType | group | attributeGroup))*
</redefine>

A <schema> information item may contain any number of <redefine> elements. Their schemaLocation attributes, consisting of a URI reference, identify other ·schema documents·, that is <schema> information items.

The ·XSD schema· corresponding to <schema> contains not only the components corresponding to its definition and declaration [children], but also all the components of all the ·XSD schemas· corresponding to any <redefine>d schema documents. Such schema documents must either (a) have the same targetNamespace as the <redefine>ing schema document, or (b) no targetNamespace at all, in which case the <redefine>d schema document is converted to the <redefine>ing schema document's targetNamespace.

The definitions within the <redefine> element itself are restricted to be redefinitions of components from the <redefine>d schema document, in terms of themselves. That is,

Type definitions must use themselves as their base type definition;
Attribute group definitions and model group definitions must be supersets or subsets of their original definitions, either by including exactly one reference to themselves or by containing only (possibly restricted) components which appear in a corresponding way in their <redefine>d selves.

Not all the components of the <redefine>d schema document need be redefined.

This mechanism is intended to provide a declarative and modular approach to schema modification, with functionality no different except in scope from what would be achieved by wholesale text copying and redefinition by editing. In particular redefining a type is not guaranteed to be side-effect free: it can have unexpected impacts on other type definitions which are based on the redefined one, even to the extent that some such definitions become ill-formed.

Note: The pervasive impact of redefinition reinforces the need for implementations to adopt some form of lazy or 'just-in-time' approach to component construction, which is also called for in order to avoid inappropriate dependencies on the order in which definitions and references appear in (collections of) schema documents.

Example

v1.xsd:
 <xs:complexType name="personName">
  <xs:sequence>
   <xs:element name="title" minOccurs="0"/>
   <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>

 <xs:element name="addressee" type="personName"/>

v2.xsd:
 <xs:redefine schemaLocation="v1.xsd">
  <xs:complexType name="personName">
   <xs:complexContent>
    <xs:extension base="personName">
     <xs:sequence>
      <xs:element name="generation" minOccurs="0"/>
     </xs:sequence>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:redefine>

 <xs:element name="author" type="personName"/>

The schema corresponding to v2.xsd has everything specified by v1.xsd, with the personName type redefined, as well as everything it specifies itself. According to this schema, elements constrained by the personName type may end with a generation element. This includes not only the author element, but also the addressee element.

Schema Representation Constraint: Redefinition Constraints and Semantics

In addition to the conditions imposed on <redefine> element information items by the schema for schema documents all of the following also apply:

1 If there are any element information items among the [children] other than <annotation> then the ·actual value· of the schemaLocation [attribute] must successfully resolve.

2 If the ·actual value· of the schemaLocation [attribute] successfully resolves one or more of the following is true:

2.1 it resolves to (a fragment of) a resource which is an XML document (see clause 1.1 of Inclusion Constraints and Semantics (§4.2.2)), which in turn corresponds to a <schema> element information item in a well-formed information set.

2.2 It resolves to a <schema> element information item in a well-formed information set.

In either case call the <redefine>d <schema> item D2 and the <redefine>ing item's parent <schema> item D1.

3 One of the following must be true:

3.1 D2 has a targetNamespace [attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace [attribute] of D1 (which must have such an [attribute]).

3.2 Neither D2 nor D1 have a targetNamespace [attribute].

3.3 D2 has no targetNamespace [attribute] (but D1 does).

4 The appropriate case among the following must be true:

4.1 If clause 3.1 or clause 3.2 above is satisfied, then

4.1.1 D2 corresponds to a conforming schema (call it S2).

4.1.2 The schema corresponding to D1 includes not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of S2, with the exception of those explicitly redefined (see Individual Component Redefinition (§4.2.3) below).

4.2 If clause 3.3 above is satisfied, then

4.2.1 Let D2′ be a <schema> information item ↓identical to D2 except that it has a targetNamespace [attribute] whose value is the same as the ·actual value· of the targetNamespace [attribute] of D1;↓ ↓↓↑obtained by performing on D2 the transformation specified in Transformation for Chameleon Inclusion (§G.1);↑ D2′ corresponds to a conforming schema (call it S2).

4.2.2 The schema corresponding to D1 includes not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of S2, with the exception of those explicitly redefined (see Individual Component Redefinition (§4.2.3) below).

Note: In this case, it is D2′ and not D2, which is required by clause 4.2.1 to correspond to a conforming schema. In particular, it is not an error for D2 to fail to satisfy all of the constraints governing schema documents, while it is an error if D2′ fails to satisfy them.

5 Within the [children], each <simpleType> must have a <restriction> among its [children] and each <complexType> must have a restriction or extension among its grand-[children] the ·actual value· of whose base [attribute] must be the same as the ·actual value· of its own name attribute plus target namespace;

6 Within the [children], for each <group> the appropriate case among the following must be true:

6.1 If it has a <group> among its contents at some level the ·actual value· of whose ref [attribute] is the same as the ·actual value· of its own name attribute plus target namespace and that <group> does not have an <element> ancestor, then all of the following are true:

6.1.1 It has exactly one such group.

6.1.2 The ·actual value· of both that group's minOccurs and maxOccurs [attribute] is 1 (or ·absent·).

6.2 If it has no such self-reference, then all of the following are true:

6.2.1 The ·actual value· of its own name attribute plus target namespace successfully ·resolves· to a model group definition in S2.

6.2.2 The {model group} of the model group definition which corresponds to it per XML Representation of Model Group Definition Schema Components (§3.7.2) accepts a subset of the element sequences accepted by that model group definition in S2. See Checking content-type restriction (non-normative) (§I) for references to techniques for checking the subset relation on content models.

7 Within the [children], for each <attributeGroup> the appropriate case among the following must be true:

7.1 If it has an <attributeGroup> among its contents the ·actual value· of whose ref [attribute] is the same as the ·actual value· of its own name attribute plus target namespace, then it has exactly one such group.

7.2 If it has no such self-reference, then all of the following are true:

7.2.1 The ·actual value· of its own name attribute plus target namespace successfully ·resolves· to an attribute group definition in S2.

7.2.2 The {attribute uses} and {attribute wildcard} of the attribute group definition which corresponds to it per XML Representation of Attribute Group Definition Schema Components (§3.6.2) viewed as the {attribute uses} and {attribute wildcard} of a Complex Type Definition and the {attribute uses} and {attribute wildcard} of that attribute group definition in S2 viewed as the {attribute uses} and {attribute wildcard} of the {base type definition} satisfy clause 3 of Derivation Valid (Restriction, Complex) (§3.4.6.3).

Note: An attribute group restrictively redefined per clause 7.2 corresponds to an attribute group whose {attribute uses} consist all and only of those attribute uses corresponding to <attribute>s explicitly present among the [children] of the <redefine>ing <attributeGroup>. No inheritance from the <redefine>d attribute group occurs. Its {attribute wildcard} is similarly based purely on an explicit <anyAttribute>, if present.

Schema Representation Constraint: Individual Component Redefinition

Corresponding to each non-<annotation> member of the [children] of a <redefine> there are one or two schema components in the <redefine>ing schema:

1 The <simpleType> and <complexType> [children] information items each correspond to two components:

1.1 One component which corresponds to the top-level definition item with the same name in the <redefine>d schema document, as defined in Schema Component Details (§3), except that its {name} is ·absent· and its {context} is the redefining component, as defined in clause 1.2 below;

1.2 One component which corresponds to the information item itself, as defined in Schema Component Details (§3), except that its {base type definition} is the component defined in clause 1.1 above.

This pairing ensures the coherence constraints on type definitions are respected, while at the same time achieving the desired effect, namely that references to names of redefined components in both the <redefine>ing and <redefine>d schema documents ·resolve· to the redefined component as specified in 1.2 above.

2 The <group> and <attributeGroup> [children] each correspond to a single component, as defined in Schema Component Details (§3), except that if and when a self-reference based on a ref [attribute] whose ·actual value· is the same as the item's name plus target namespace is ·resolved·, a component which corresponds to the top-level definition item of that name and the appropriate kind in S2 is used.

In all cases there must be a top-level definition item of the appropriate name and kind in the <redefine>d schema document.

Note: The above is carefully worded so that multiple equivalent <redefine>ing of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (§3.17.6.1), but applications are allowed, indeed encouraged, to avoid <redefine>ing the same schema document in the same way more than once to forestall the necessity of establishing identity component by component (although this will have to be done for the individual redefinitions themselves).

4.2.4 Overriding component definitions (`<override>`)

The <redefine> construct defined in Including modified component definitions (<redefine>) (§4.2.3) is useful in schema evolution and versioning, when it is desirable to have some guaranteed restriction or extension relation between the old component and the redefined component. But there are occasions when the schema author simply wants to replace old components with new ones without any constraint. Also, existing XSD processors have implemented conflicting and non-interoperable interpretations of <redefine>, and the <redefine> construct is ·deprecated·. The <override> construct defined in this section allows such unconstrained replacement.

Note: The name of the <override> element has nothing to do with the use of the term "·override·" to denote the relation between an ·instance-specified type definition· and another type. The two mechanisms are distinct and unrelated.

XML Representation Summary: override Element Information Item

<override
  id = ID
  schemaLocation = anyURI
  {any attributes with non-schema namespace . . .}>
  Content: (annotation | (simpleType | complexType | group | attributeGroup | element | attribute | notation))*
</override>

A <schema> information item may contain any number of <override> elements. Their schemaLocation attributes, consisting of a URI reference, identify ("point to") other ·schema documents·, that is <schema> information items.

The ·XSD schema· corresponding to <schema> contains not only the components corresponding to its definition and declaration [children], but also all the components mapped to by the (possibly modified) source declarations in any overridden schema documents (after the modifications described below). Overridden schema documents must either (a) have the same targetNamespace as the overriding schema document, or (b) no targetNamespace at all, in which case the overridden schema document is converted to the overriding schema document's targetNamespace.

The overriding schema document may override any source declarations for ·named· components which appear among the [children] of the <schema>, <redefine>, or <override> elements in the overridden schema document.

Note: Source declarations not present in the overridden schema document cannot be overridden, even if they are present in other schema documents included by the overridden schema document. The same is true for source declarations in redefined and overridden schema documents: if schema document D1 overrides schema document D2, which in turn includes a <redefine> or <override> element pointing to schema document D3, only the source declarations present as [children] of the <redefine> or <override> in D2 can be overridden in D1, not the other contents of D3.

The definitions within the <override> element itself are not required to be similar in any way to the source declarations being overridden. Not all the source declarations of the overridden schema document need be overridden.

As this mechanism is very similar to <redefine>, many similar kinds of caution need to be taken in using <override>. Please refer to Including modified component definitions (<redefine>) (§4.2.3) for details.

Example

v1.xsd:
 <xs:complexType name="personName">
  <xs:sequence>
   <xs:element name="firstName"/>
   <xs:element name="lastName"/>
  </xs:sequence>
 </xs:complexType>

 <xs:element name="addressee" type="personName"/>

v2.xsd:
 <xs:override schemaLocation="v1.xsd">
  <xs:complexType name="personName">
   <xs:sequence>
    <xs:element name="givenName"/>
    <xs:element name="surname"/>
   </xs:sequence>
  </xs:complexType>
 </xs:override>

 <xs:element name="author" type="personName"/>

The schema corresponding to v1.xsd has a complex type named personName children with a sequence of firstName and lastName. The schema corresponding to v2.xsd overrides personName, by providing a different sequence of element children. All elements with the personName type are now constrained to have the sequence of givenName and surname. This includes not only the author element, but also the addressee element.

Schema Representation Constraint: Override Constraints and Semantics

In addition to the conditions imposed on <override> element information items by the schema for schema documents all of the following also apply:

1 If there are any element information items among the [children] other than <annotation> then the ·actual value· of the schemaLocation [attribute] must successfully resolve.

2 If the ·actual value· of the schemaLocation [attribute] successfully resolves one or more of the following is true:

2.1 It resolves to (a fragment of) a resource which is an XML document (see clause 1.1 of Inclusion Constraints and Semantics (§4.2.2)), which in turn corresponds to a <schema> element information item in a well-formed information set.

2.2 It resolves to a <schema> element information item in a well-formed information set.

In either case call the overridden <schema> item D2 and the overriding item's parent <schema> item D1.

3 One of the following must be true:

3.1 D2 has a targetNamespace [attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace [attribute] of D1 (which must have such an [attribute]).

3.2 Neither D2 nor D1 have a targetNamespace [attribute].

3.3 D2 has no targetNamespace [attribute] (but D1 does).

4 The appropriate case among the following must be true:

4.1 If clause 3.1 or clause 3.2 above is satisfied, then

4.1.1 Let D2′ be a <schema> information item obtained by ↑obtained by performing on D2 the transformation specified in ↓Stylesheet↓↑Transformation↑ for xs:override (§G.2)↑. Then D2′ corresponds to a conforming schema (call it S2).

4.1.2 The <override> element in schema document D1 pointing to D2 is replaced by an <include> element pointing to D2′ and the inclusion is handled as described in Assembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.2).

Note: It is not necessary to perform a literal replacement of the <override> element in D1 with an <include> element; any implementation technique can be used as long as it produces the required result.

Note: One effect of the rule just given is that the schema corresponding to D1 includes not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of S2.

Note: Another effect is that if schema document A contains a source declaration for a component E, and schema document B overrides A with its own declaration for E, and schema document C in turn overrides B with a third declaration for E, then

4.1.2.1 First, the override of B by C is handled. The resulting schema document still contains an <override> element referring to C, but the declaration for E contained in it has been replaced by that specified in C.

4.1.2.2 Then, the override of A by (the modified version of) B is handled.

4.1.2.3 The resulting version of A, containing the declaration for E originally present in C, is included by the modified version of B, which is itself included by C.

4.1.2.4 The resulting schema contains the version of E originally specified in schema document C.

(The references to "first" and "next" here refer to the logical precedence of operations, not to a required order in which implementations are required to perform particular tasks.)

4.2 If clause 3.3 above is satisfied, then

4.2.1 Let D2′ be a <schema> information item obtained by ↑obtained by performing on D2 first the transformation specified in Transformation for Chameleon Inclusion (§G.1) and then the transformation specified in ↓Stylesheet↓↑Transformation↑ for xs:override (§G.2)↑. Then D2′ corresponds to a conforming schema (call it S2).

4.2.2 The <override> element in schema document D1 pointing to D2 is replaced by an <include> element pointing to D2′ and the inclusion is handled as described in Assembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.2).

5 For each non-<annotation> member of the [children] of an <override>, there must be a definition item of the appropriate name and kind that is a [child] of <schema>, <redefine>, or <override> in D2.

Note: The effect of applying the stylesheet in ↓Stylesheet↓↑Transformation↑ for xs:override (§G.2) is to make D2′ identical to D2 except that some elements in D2 are replaced with those in D1's <override> (call it O1), as follows. For each element information item E2 in the [children] of D2's <schema>, <redefine>, or <override> information item, the appropriate case among the following is true:

1 If O1 has a child E1 with the same element type (<simpleType>, <complexType>, <group>, <attributeGroup>, <element>, <attribute>, or <notation>) and the same value for its name attribute, then D2′ has an element identical to E1 in E2's place.

2 If O1 has no such child, then D2′ has an element identical to E2 in the same place as where E2 is in D2.

Implementations do not have to use [XSLT 2.0] transformation, as long as the same result is produced.

Note: It is D2′ and not D2, which is required to correspond to a conforming schema. In particular, it is not an error for D2 to fail to satisfy all of the constraints governing schema documents, while it is an error if D2′ fails to satisfy them.

Note: In <redefine>, components are allowed or required to refer to themselves. There is no similar special treatment in <override>. Overriding components are constructed as if the overridden components had never existed.

Note: The above is carefully worded so that multiple equivalent overrides of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (§3.17.6.1), but applications are allowed, indeed encouraged, to avoid overriding the same schema document in the same way more than once to forestall the necessity of establishing identity component by component.

Note: It is a consequence of the semantics of inclusion, as defined in Inclusion Constraints and Semantics (§4.2.2) (in particular clause 3.1.2 and clause 3.2.2); redefinition, as defined in Including modified component definitions (<redefine>) (§4.2.3); import, as defined in References to schema components across namespaces (<import>) (§4.2.5); 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.

...

W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures

Editor's Draft 2 September 2008

Status of this Document

Table of Contents

Appendices

4 Schemas and Namespaces: Access and Composition

4.2 Layer 2: Schema Documents, Namespaces and Composition

4.2.2 Assembling a schema for a single target namespace from multiple schema definition documents (`<include>`)

4.2.3 Including modified component definitions (`<redefine>`)

4.2.4 Overriding component definitions (`<override>`)

G Stylesheets for Composing Schema Documents (Normative)

G.1 Transformation for Chameleon Inclusion

G.2 ↓Stylesheet↓↑Transformation↑ for `xs:override`