What Is xs:redefine in XML Schema and Why Is It Deprecated

The xs:redefine element in XML Schema (XSD) is a mechanism introduced in XSD 1.0 to include external schema components while simultaneously modifying their definitions within the same namespace. While intended to provide schema reusability and type inheritance, xs:redefine introduced significant architectural flaws, semantic ambiguities, and processor inconsistencies. As a result, the W3C deprecated xs:redefine in XML Schema 1.1 in favor of the more robust and predictable xs:override element.

What Is the xs:redefine Element?

In XML Schema 1.0, xs:redefine allows a schema document to import definitions from another schema file that shares the same target namespace and alter specific declarations. Unlike a standard xs:include, which incorporates external declarations without modification, xs:redefine allows you to alter:

• Complex types
• Simple types
• Model groups (xs:group)
• Attribute groups (xs:attributeGroup)

When redefining a component, the new definition must use the original component as its base type (using extension or restriction) or directly replace the internal particle structure of a group.

<xs:redefine schemaLocation="baseSchema.xsd">
  <xs:complexType name="CustomerType">
    <xs:complexContent>
      <xs:extension base="CustomerType">
        <xs:sequence>
          <xs:element name="loyaltyTier" type="xs:string"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
</xs:redefine>

In the example above, CustomerType is extended to include a new element (loyaltyTier) without requiring a new type name.

Why Was xs:redefine Deprecated?

Although useful in theory for versioning and modular design, xs:redefine caused critical operational and conceptual issues in practice.

1. Pervasive and Non-Local Side Effects

When a component is redefined using xs:redefine, the change applies globally across the entire schema context where the redefining document is loaded. This “pervasive” mutation means any other components referencing the original type automatically receive the redefined version, often leading to unintended side effects in modular or enterprise-level schema repositories.

2. Self-Referential Ambiguity

xs:redefine requires a type to refer to itself during its own redefinition (e.g., CustomerType extending CustomerType). This breaks standard scoping rules, creating circular dependency issues and making schemas difficult to read, validate, and maintain.

3. Inconsistent Processor Behavior

Because the XSD 1.0 specification left edge cases under-defined—especially regarding multi-level redefinitions and interactions with xs:import—different XSD validators (such as Apache Xerces, Saxon, and Microsoft .NET XML parsers) implemented resolution rules inconsistently. A schema using xs:redefine that validated successfully in one tool often failed in another.

4. Restriction Violations

Redefining simple types or complex types via restriction frequently violated the Liskov Substitution Principle and basic type safety rules, causing subtle validation errors that were difficult to debug.

The Modern Alternative: xs:override

In XML Schema 1.1, the W3C deprecated xs:redefine and introduced xs:override.

Unlike xs:redefine, xs:override: * Fully replaces the target component rather than relying on self-referential mutation. * Can replace any schema component, including elements and attributes, not just types and groups. * Follows well-defined, deterministic rules across all compliant XSD 1.1 processors.

For modern XML design, schemas should rely on standard type derivation (xs:extension and xs:restriction under new type names) or xs:override in XSD 1.1 environments to ensure long-term stability and interoperability.