Chapter 18. Redefining and overriding schema components
There are two methods of including a schema document into a schema while modifying or overriding certain parts of it: redefine and override. Redefinition—a version 1.0 feature—allows you to extend or restrict certain components (namely types and groups), replacing the original definitions, but only in certain constrained ways. Because of the limitations of redefinition and its inconsistent implementation among processors, redefinition was deprecated in version 1.1 and replaced with a new override feature which is more flexible and better defined.
For the sake of completeness, redefinition is covered in the first half of this chapter. However, it being deprecated, in version 1.1 you are strongly encouraged to use the override feature instead if you require this kind of functionality. Overrides are described in the second half of this chapter.1
18.1. Redefinition
Redefinition is a way to extend and modify schemas over time while still reusing the original definitions. It involves defining a new version of a schema component, with the same name, that replaces the original definition throughout the schema. This is useful for extending and/or creating a subset of an existing schema.
18.1.1. Redefinition basics
A redefine is similar to an include, with the additional option of specifying new definitions of some or all of the components in the redefined schema document. This is depicted in Figure 18–1. Like included schema documents, redefined schema documents must have the same target namespace as the redefining schema document, or none at all.
Figure 18–1. Redefine
Only certain types of schema components can be redefined, namely complex types, simple types, named model groups, and attribute groups. The new definitions must be based on the original definitions. For types, this means that the new type must restrict or extend the original type. For attribute groups and named model groups, it means that the new group must either be a subset or a superset of the original group.
Example 18–1 shows a simple redefinition where the schema document prod2.xsd redefines prod1.xsd. The simple type DressSizeType is redefined in prod2.xsd.
Example 18–1. A simple redefinition
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="DressSizeType">
<xs:restriction base="xs:integer"/>
</xs:simpleType>
<xs:element name="size" type="DressSizeType"/>
<xs:element name="color" type="xs:string"/>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://datypic.com/prod"
targetNamespace="http://datypic.com/prod">
<xs:redefine schemaLocation="prod1.xsd">
<xs:simpleType name="DressSizeType">
<xs:restriction base="DressSizeType">
<xs:minInclusive value="2"/>
<xs:maxInclusive value="16"/>
</xs:restriction>
</xs:simpleType>
</xs:redefine>
<xs:element name="newSize" type="DressSizeType"/>
</xs:schema>
18.1.1.1. Include plus redefine
When a schema document is redefined, all of its components are included in the redefining schema document, regardless of whether they are specifically mentioned in the redefinition. In this way, the redefine feature is similar to the include feature. In our example, the resulting schema document includes all of the components defined and declared in both prod2.xsd and prod1.xsd. Even though color is not mentioned in prod2.xsd, it will be included in the resulting schema document.
18.1.1.2. Redefine and namespaces
The target namespace of the redefined schema document must be the same as that of the redefining schema document, or nonexistent. If the redefined schema document does not have a target namespace, all of its components become chameleon components and will take on the target namespace of the redefining schema document. For example, since prod1.xsd does not have a target namespace, all of its components will take on the target namespace of prod2.xsd. This includes color, which is not specifically mentioned in the redefinition. It is not a problem that the size element declaration in prod1.xsd references DressSizeType without a prefix; the processor will correctly interpret the references between components.
18.1.1.3. Pervasive impact
Once a schema is redefined, the new definitions completely replace the original definitions—not just for components in the new (redefining) schema document, but also for components that reference them in the original (redefined) schema document. In Example 18–1, the size element declaration now uses the new DressSizeType. If there had been types derived from DressSizeType in prod1.xsd, they would now become derived from the new DressSizeType.
Redefinition of a component has a ripple effect on all the other components that depend on it. For a type, that includes all other types that are derived from it at any level. For a group, that includes all complex types that reference it, as well as the types derived from those types. While this is generally intentional and desirable, there is no guarantee that you will not break these dependent components, and schema processors are not required to warn you if you do. Specific risks associated with redefinition are described in Section 18.3 on p. 468.
For a comparison of redefinition, type derivation, and other methods of extending schemas see Section 22.2 on p. 599.
18.1.2. The mechanics of redefinition
A redefine element is used to contain redefined schema components. A redefine element may only occur at the top level of a schema document (with schema as its parent), and all redefine children must be at the beginning of the schema document, along with the include, import, and override elements. The syntax for a redefine element is shown in Table 18–1.
Table 18–1. XSD Syntax: redefinition
A schema document can contain multiple redefinitions of various other schema documents. The schemaLocation attribute indicates the location of the schema document to be redefined. It must reference a complete schema document with schema as its root element. As mentioned above, the redefined schema document must have the same target namespace as the redefining schema document, or none at all.
The redefine element contains the new definitions of the schema components, in any order. For every definition that appears in a redefine element, there must be a corresponding definition (with the same qualified name) in the redefined schema document. Only the components that need to be modified should appear in the redefine element. All other components of the redefined schema document will be included in the new schema as is. In fact, a redefine element is not required to have any children at all, in which case it acts exactly like an include element.
18.1.3. Redefining simple types
When redefining a simple type, the new definition must restrict the original simple type. Example 18–2 shows how you would redefine DressSizeType to change minInclusive to be 2. The restricted DressSizeType uses itself as the base type. Redefinition is the only case where a simple type can restrict itself.
The redefinition of DressSizeType affects not only the newSize element declaration in prod2.xsd, but also the size element declaration in prod1.xsd. Because of the redefinition, size instances that conform to prod2.xsd cannot have the value 0. This illustrates the effect redefinition has on components in the original schema.
Example 18–2. Redefining a simple type
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="DressSizeType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="18"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="size" type="DressSizeType"/>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:redefine schemaLocation="prod1.xsd">
<xs:simpleType name="DressSizeType">
<xs:restriction base="DressSizeType">
<xs:minInclusive value="2"/>
</xs:restriction>
</xs:simpleType>
</xs:redefine>
<xs:element name="newSize" type="DressSizeType"/>
</xs:schema>
18.1.4. Redefining complex types
Complex types can also be redefined, provided that the new definition of the complex type either extends or restricts the original complex type. Example 18–3 shows how you would redefine ProductType to add a new element declaration and a new attribute declaration. Like a simple type, a complex type can be based on itself when it is part of a redefinition.
Example 18–3. Redefining a complex type
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="ProductType">
<xs:sequence>
<xs:element name="number" type="xs:integer"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="size" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:redefine schemaLocation="prod1.xsd">
<xs:complexType name="ProductType">
<xs:complexContent>
<xs:extension base="ProductType">
<xs:sequence>
<xs:element name="color" type="xs:string"/>
</xs:sequence>
<xs:attribute name="effDate" type="xs:date"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
</xs:schema>
18.1.5. Redefining named model groups
When redefining named model groups, the new definition must be either a subset or a superset of the original group.
18.1.5.1. Defining a subset
Example 18–4 shows the redefinition of DescriptionGroup to disallow the comment element.
Example 18–4. Redefining a named model group as a subset
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:group name="DescriptionGroup">
<xs:sequence>
<xs:element name="description" type="xs:string"/>
<xs:element name="comment" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:group>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:redefine schemaLocation="prod1.xsd">
<xs:group name="DescriptionGroup">
<xs:sequence>
<xs:element name="description" type="xs:string"/>
</xs:sequence>
</xs:group>
</xs:redefine>
</xs:schema>
Our example is legal because the comment elements are optional per the original definition. The exact definition of a legal subset is the same as that used for complex type restriction. In other words, if a content model is considered a legal restriction of another content model (in complex type derivation), it is also a legal subset in the redefinition of a named model group. See Section 13.5 on p. 316 for the rules of complex type restriction.
18.1.5.2. Defining a superset
On the other hand, suppose you want to extend the definition of DescriptionGroup to include more children. Example 18–5 shows the redefinition of DescriptionGroup to add new element declarations. In this case, you are saying that you want all of the original element declarations of DescriptionGroup, followed by the new notes element declaration.
Example 18–5. Redefining a named model group as a superset
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:group name="DescriptionGroup">
<xs:sequence>
<xs:element name="description" type="xs:string"/>
<xs:element name="comment" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:group>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:redefine schemaLocation="prod1.xsd">
<xs:group name="DescriptionGroup">
<xs:sequence>
<xs:group ref="DescriptionGroup"/>
<xs:element name="notes" type="xs:string"/>
</xs:sequence>
</xs:group>
</xs:redefine>
</xs:schema>
The group refers to itself the way it would refer to any other group. Redefinition is the only case where a group reference can be circular, but there are two constraints.
• The group may only reference itself once.
• maxOccurs and minOccurs of that self-reference must be 1 (or not present, in which case they default to 1).
18.1.6. Redefining attribute groups
Like a named model group, an attribute group can be redefined to be a subset or superset of its original definition.
18.1.6.1. Defining a subset
Example 18–6 shows how you would redefine the IdentifierGroup as a subset. The new definition disallows the xml:lang attribute and changes the type of the version attribute from decimal to integer.
Example 18–6. Redefining an attribute group as a subset
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:attributeGroup name="IdentifierGroup">
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="version" type="xs:decimal"/>
<xs:attribute ref="xml:lang"/>
</xs:attributeGroup>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:redefine schemaLocation="prod1.xsd">
<xs:attributeGroup name="IdentifierGroup">
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="version" type="xs:integer"/>
</xs:attributeGroup>
</xs:redefine>
</xs:schema>
The rules used to define a subset of an attribute group are the same as those used for attribute restriction in complex type derivation. This means that you can eliminate optional attributes, make attributes required, add a fixed value, change default values, or change types to be more restrictive. Eliminating the xml:lang attribute in Example 18–6 is legal because it is optional (by default) in the original attribute group. Changing the type of version is legal because integer is a restriction of decimal. See Section 13.5.5 on p. 333 for more information on attribute restrictions.
Unlike complex type derivation, however, you must redeclare all attributes you want to appear in the new definition. The attribute declarations will not automatically be copied from the original definition to the new definition.
If the original definition contains an attribute wildcard, you may repeat or further restrict the wildcard. Subsetting of attribute wildcards also follows the rules used in complex type derivation. See Section 13.5.6 on p. 335 for more information on attribute wildcard restrictions.
18.1.6.2. Defining a superset
On the other hand, suppose you want to extend the definition of IdentifierGroup to include more attributes. Example 18–7 shows how you would redefine IdentifierGroup to add attributes. You cannot alter the declarations of the attributes in the original group, only add new attributes. In this case, you are saying that you want all of the original attributes of IdentifierGroup, plus a new effDate attribute.
Example 18–7. Redefining an attribute group as a superset
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:attributeGroup name="IdentifierGroup">
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="version" type="xs:decimal"/>
<xs:attribute ref="xml:lang"/>
</xs:attributeGroup>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:redefine schemaLocation="prod1.xsd">
<xs:attributeGroup name="IdentifierGroup">
<xs:attributeGroup ref="IdentifierGroup"/>
<xs:attribute name="effDate" type="xs:date"/>
</xs:attributeGroup>
</xs:redefine>
</xs:schema>
The attribute group refers to itself the way it would refer to any other attribute group. Redefinition is the only case where an attribute group reference can be circular in version 1.0.
18.2. Overrides
The override feature is a convenient way to customize schemas. It involves defining a new version of a schema component, with the same name, that replaces the original definition throughout the schema. This is useful when you want to reuse a schema but you want to make some modifications (minor or major) to the components in that schema while still preserving the original definitions.
18.2.1. Override basics
An override is similar to an include, with the additional option of specifying new definitions for some or all of the components in the overridden schema document. This is depicted in Figure 18–2. Like included schema documents, overridden schema documents must have the same target namespace as the overriding schema document, or none at all.
Figure 18–2. Override
You can override any top-level named schema component, namely complex types, simple types, global element declarations, global attribute declarations, named model groups, attribute groups, and notations. Unlike redefines, the new definitions do not have to be based on the original definitions. In fact, they cannot refer to the original definitions in the way that redefining components do.
Example 18–8 shows a simple override where the schema document prod2.xsd overrides prod1.xsd. The simple type DressSizeType is overridden in prod2.xsd.
Example 18–8. A simple override
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="DressSizeType">
<xs:restriction base="xs:integer"/>
</xs:simpleType>
<xs:element name="size" type="DressSizeType"/>
<xs:element name="color" type="xs:string"/>
</xs:schema>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://datypic.com/prod"
targetNamespace="http://datypic.com/prod">
<xs:override schemaLocation="prod1.xsd">
<xs:simpleType name="DressSizeType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="2"/>
<xs:maxInclusive value="16"/>
</xs:restriction>
</xs:simpleType>
</xs:override>
<xs:element name="newSize" type="DressSizeType"/>
</xs:schema>
18.2.1.1. Include plus override
When a schema document is overridden, all of its components are included in the overriding schema document, regardless of whether they are specifically mentioned in the override. In this way, the override feature is similar to the include feature. In our example, the resulting schema document includes all of the components defined and declared in both prod2.xsd and prod1.xsd. Even though color is not mentioned in prod2.xsd, it will be included in the resulting schema document.
18.2.1.2. Override and namespaces
The target namespace of the overridden schema document must be the same as that of the overriding schema document, or nonexistent. If the overridden schema document does not have a target namespace, all of its components become chameleon components and will take on the target namespace of the overriding schema document. For example, since prod1.xsd does not have a target namespace, all of its components will take on the target namespace of prod2.xsd. This includes color, which is not specifically mentioned in the override. It is not a problem that the size element declaration in prod1.xsd references DressSizeType without a prefix; the processor will correctly interpret the references between components.
18.2.1.3. Pervasive impact
Once a schema is overridden, the new definitions completely replace the original definitions—not just for components in the new overriding schema document, but also for components that reference it in the original, overridden schema document. In Example 18–8, the size element declaration now uses the new DressSizeType. If there had been types derived from DressSizeType in prod1.xsd, they would now be derived from the new DressSizeType.
Overriding a component has a ripple effect on all the other components that depend on it. For a type, this includes all other types that are derived from it at any level. For a group, it includes all complex types that reference it, as well as the types derived from those types. While this is generally intentional and desirable, there is no guarantee that you will not break these dependent components, and schema processors are not required to warn you if you do. Specific risks associated with overrides are described in Section 18.3 on p. 468.
For a comparison of overriding, type derivation, and other methods of extending schemas, see Section 22.2 on p. 599.
18.2.2. The mechanics of overriding components
An override element is used to contain overridden schema components. An override element may only occur at the top level of a schema document (with schema as its parent), and all override children must be at the beginning of the schema document, along with the include, import, and redefine elements. The syntax for an override element is shown in Table 18–2.
Table 18–2. XSD Syntax: override
A schema document can contain multiple overrides of various other schema documents. The schemaLocation attribute indicates the location of the schema document to be overridden. It must reference a complete schema document with schema as its root element. As mentioned above, the overridden schema document must have the same target namespace as the overriding schema document, or none at all.
The override element contains the new definitions of the schema components, in any order. For every definition that appears in an override element, there must be a corresponding definition (with the same qualified name) in the overridden schema document. Only the components that need to be modified should appear in the override element. All other components of the overridden schema document will be included in the new schema as is. In fact, an override element is not required to have any children at all, in which case it acts exactly like an include element.
18.2.3. Overriding simple types
Example 18–9 shows how you would override a simple type DressSizeType to change minInclusive to be 2. Unlike redefinition, the overriding type DressSizeType in prod2.xsd is not derived from or in any way related to its counterpart in prod1.xsd. Even though the maxInclusive constraint didn’t change, it needs to be respecified in the overriding type.
Example 18–9. Overriding a simple type
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="DressSizeType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="18"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="size" type="DressSizeType"/>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:override schemaLocation="prod1.xsd">
<xs:simpleType name="DressSizeType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="2"/>
<xs:maxInclusive value="18"/>
</xs:restriction>
</xs:simpleType>
</xs:override>
<xs:element name="newSize" type="DressSizeType"/>
</xs:schema>
The override of DressSizeType affects not only the newSize element declaration in prod2.xsd, but also the size element declaration in prod1.xsd. Because of the override, size instances that conform to prod2.xsd cannot have the value 0. This illustrates the effect overriding has on components in the original schema.
In this example, DressSizeType didn’t change much. It is still based on integer but with some additional constraints. However, you are not limited in the changes you can make when overriding, as long as the overriding definition is still a simple type. It would be possible to turn DressSizeType into a string value, for example. It is not possible to override a simple type with a complex type.
18.2.4. Overriding complex types
Complex types can also be overridden. Example 18–10 shows how you would override ProductType to change the type of number, delete size, and add color. As with simple types, the overriding definition can be similar to the overridden definition, as it is in this case, but it can also be completely different.
Example 18–10. Overriding a complex type
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="ProductType">
<xs:sequence>
<xs:element name="number" type="xs:integer"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="size" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:override schemaLocation="prod1.xsd">
<xs:complexType name="ProductType">
<xs:sequence>
<xs:element name="number" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="color" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:override>
</xs:schema>
18.2.5. Overriding element and attribute declarations
Unlike redefines, overrides can apply to element and attribute declarations, as long as they are global. Example 18–11 shows the override of the description global element declaration and the version global attribute declaration. In this case, description changed significantly, from having a simple type to having a complex type with element-only content.
Example 18–11. Overriding element and attribute declarations
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="description" type="xs:string"/>
<xs:attribute name="version" type="xs:decimal"/>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:override schemaLocation="prod1.xsd">
<xs:element name="description" type="DescriptionType"/>
<xs:attribute name="version" type="xs:string" default="1.0"/>
</xs:override>
<xs:complexType name="DescriptionType">
<xs:sequence>
<xs:element name="source" type="xs:string"/>
<xs:element name="content" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Local element and attribute declarations cannot be overridden directly, but the complex types that contain them can be.
18.2.6. Overriding named groups
It is also possible to override named model groups and attribute groups. Unlike a redefinition, the new definition of a group has no superset or subset relationship to the original group definition.
Example 18–12 shows an override of the DescriptionGroup named model group and the IdentifierGroup attribute group.
Example 18–12. Overriding named groups
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:group name="DescriptionGroup">
<xs:sequence>
<xs:element name="description" type="xs:string"/>
<xs:element name="comment" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:attributeGroup name="IdentifierGroup">
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="version" type="xs:decimal"/>
</xs:attributeGroup>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:override schemaLocation="prod1.xsd">
<xs:group name="DescriptionGroup">
<xs:sequence>
<xs:element name="description" type="xs:string"/>
</xs:sequence>
</xs:group>
<xs:attributeGroup name="IdentifierGroup">
<xs:attribute name="effDate" type="xs:date"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:attributeGroup>
</xs:override>
</xs:schema>
18.3. Risks of redefines and overrides
As mentioned previously, redefines and overrides both have a pervasive impact on all components—not just in the overriding/redefining schema document, but also in the overridden/redefined schema document. When you use either of these techniques, if there are other components that depend on the original definitions, you run the risk of rendering these dependent components invalid by changing the original definitions.
18.3.1. Risks of redefining or overriding types
For a type, the risks pertain to all other types that are derived from it at any level.
Example 18–13 shows a new prod1.xsd where there are two complex types derived from ProductType: ShirtType (an extension) and RestrictedProductType (a restriction). All changes to ProductType during override or redefine are passed down to the derived types, which is probably your intention. However, in this case, both derived types have been rendered illegal.
Example 18–13. Risks of overriding types
prod1.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="ProductType">
<xs:sequence>
<xs:element name="number" type="xs:integer" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="size" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ShirtType">
<xs:complexContent>
<xs:extension base="ProductType">
<xs:sequence>
<xs:element name="color" type="xs:integer"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="RestrictedProductType">
<xs:complexContent>
<xs:restriction base="ProductType">
<xs:sequence>
<xs:element name="number" type="xs:integer"
minOccurs="0"/>
<xs:element name="size" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
prod2.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:override schemaLocation="prod1.xsd">
<xs:complexType name="ProductType">
<xs:sequence>
<xs:element name="number" type="xs:integer"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="color" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:override>
</xs:schema>
Some of the risks associated with redefining or overriding ProductType when there are extensions of the original definition are:
• Adding an attribute that ShirtType already has, resulting in duplicate attributes for ShirtType.
• Adding an element declaration to the content model that ShirtType already has, but with a different type, as shown in Example 18–13 with color. It is illegal for a complex type to contain two element declarations with the same name and different types.
• Adding element declarations to the content model that render the content model of ShirtType nondeterministic.
Some of the risks associated with redefining or overriding ProductType when there are restrictions of the original definition are:
• Restricting a content model further, or in a way incompatibly different, than how RestrictedProductType restricted it, as shown in Example 18–13.
• Restricting an attribute further than RestrictedProductType restricted it, rendering RestrictedProductType’s restriction illegal.
• Making an attribute, which is then restricted by RestrictedProductType, prohibited, resulting in an illegal attribute declaration in the definition of RestrictedProductType.
Simple type derivations can also be negatively affected by redefines and overrides. As with complex types, if there are dependent types in the original schema document that restrict an overridden simple type further or in incompatible ways, it can render them invalid.
18.3.2. Risks of redefining or overriding named groups
When redefining or overriding a named group, you should be aware of an impact to the complex types that reference it, as well as the types derived from those types. The risks include:
• Making a content model nondeterministic.
• Introducing duplicate attribute names.
• Making element declarations inconsistent by introducing two element declarations with the same name but different types.
• Rendering illegal the types derived by extension or restriction from the types that directly use the group, in the ways described in the previous section.