Understanding xs:redefine for XML Schema Types

The xs:redefine element in XML Schema Definition (XSD) allows a schema to incorporate declarations from an external schema document while simultaneously modifying the definitions of complex types, simple types, model groups, or attribute groups. This article explains the exact behavior, constraints, and semantics of xs:redefine when applied specifically to simple and complex type definitions.

Core Mechanics of xs:redefine

When using xs:redefine, the redefining schema acts similarly to an xs:include, bringing external components into the target schema’s namespace. However, child elements within xs:redefine can alter specific existing types.

For type definitions (xs:simpleType and xs:complexType), the fundamental rule of xs:redefine is self-derivation: the new type definition must use the original type definition as its base type through either extension or restriction.

Redefining Complex Types

When redefining an xs:complexType, the following rules apply:

1. Self-Reference: The redefining xs:complexType must contain an xs:extension or xs:restriction whose base attribute references the exact name of the type being redefined.
2. Extension Behavior: If using xs:extension, the new elements or attributes are appended to the content model of the original type definition according to standard derivation rules.
3. Restriction Behavior: If using xs:restriction, the new definition must be a valid structural restriction of the original type, adhering to standard particle restriction rules (e.g., tightening occurrences, fixing values, or narrowing types).

<!-- Original Schema (types.xsd) -->
<xs:complexType name="AddressType">
    <xs:sequence>
        <xs:element name="street" type="xs:string"/>
        <xs:element name="city" type="xs:string"/>
    </xs:sequence>
</xs:complexType>

<!-- Redefining Schema -->
<xs:redefine schemaLocation="types.xsd">
    <xs:complexType name="AddressType">
        <xs:complexContent>
            <xs:extension base="AddressType">
                <xs:sequence>
                    <xs:element name="country" type="xs:string"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
</xs:redefine>

Redefining Simple Types

When redefining an xs:simpleType:

1. Restriction Only: Simple types can only be redefined using xs:restriction. Extension is not supported for simple types because simple types cannot add new structural elements or attributes.
2. Base Attribute: The base attribute of the xs:restriction element must reference the name of the xs:simpleType being redefined.
3. Facet Tightening: The redefining simple type applies additional or more restrictive facets (such as xs:maxLength, xs:pattern, or xs:enumeration) to the original base type.

<!-- Original Schema (types.xsd) -->
<xs:simpleType name="ZipCodeType">
    <xs:restriction base="xs:string"/>
</xs:simpleType>

<!-- Redefining Schema -->
<xs:redefine schemaLocation="types.xsd">
    <xs:simpleType name="ZipCodeType">
        <xs:restriction base="ZipCodeType">
            <xs:pattern value="\d{5}(-\d{4})?"/>
        </xs:restriction>
    </xs:simpleType>
</xs:redefine>

Pervasive Effect (Global Substitution)

The alteration caused by xs:redefine is pervasive. Once a type is redefined:

• The new definition completely replaces the old definition throughout the entire schema composition.
• Any other elements or types within the included schema (or schemas that include it) that reference the modified type name will automatically resolve to the redefined version.
• The original definition ceases to exist independently in the schema processor’s symbol space.

Namespace Constraints

• Same Namespace: The redefined schema must have the same targetNamespace as the redefining schema, or it must have no target namespace (chameleon schema approach).
• Qualified Names: When referencing the base type inside the redefinition, the prefix must match the target namespace of the schema if one is defined.

Key Differences and Limitations

• No Arbitrary Replacement: Unlike standard inheritance, you cannot redefine a type to derive from a completely different base type (e.g., redefining MyType by deriving from xs:int if it originally derived from xs:string).
• Deprecation in XSD 1.1: Due to complexities and ambiguities in schema component model resolution, xs:redefine is deprecated in XSD 1.1 in favor of the more flexible and predictable xs:override element, which does not require self-derivation.