Table of contents

Appendices

4.5 Redefining Types & Groups

ref52 In [A Schema in Multiple Documents] we described how to include definitions and declarations obtained from external schema files having the same target namespace. The include mechanism enables you to use externally created schema components "as-is", that is, without any modification. We have just described how to derive new types by extension and by restriction, and the redefine mechanism we describe here enables you to redefine simple and complex types, groups, and attribute groups that are obtained from external schema files. Like the include mechanism, redefine requires the external components to be in the same target namespace as the redefining schema, although external components from schemas that have no namespace can also be redefined. In the latter cases, the redefined components become part of the redefining schema's target namespace.

To illustrate the redefine mechanism, we use it instead of the include mechanism in the International Purchase Order schema, ipo.xsd, and we use it to modify the definition of the complex type Address contained in address.xsd:

NOTE: 

Using redefine in the International Purchase Order

<schema targetNamespace="http://www.example.com/IPO"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ipo="http://www.example.com/IPO">

  <!-- bring in address constructs -->
  <redefine
    schemaLocation="http://www.example.com/schemas/address.xsd">

    <!-- redefinition of Address -->
    <complexType name="Address">
      <complexContent>
        <extension base="ipo:Address">
          <sequence>
            <element name="country" type="string"/>
          </sequence>
        </extension>
      </complexContent>
    </complexType>

  </redefine>

  <!-- etc. -->

</schema>

The redefine element acts very much like the include element as it includes all the declarations and definitions from the address.xsd file. The complex type definition of Address uses the familiar extension syntax to add a country element to the definition of Address. However, note that the base type is also Address. Outside of the redefine element, any such attempt to define a complex type with the same name (and in the same namespace) as the base from which it is being derived would cause an error. But in this case, there is no error, and the extended definition of Address becomes the only definition of Address.

Now that Address has been redefined, the extension applies to all schema components that make use of Address. For example, address.xsd contains definitions of international address types that are derived from Address. These derivations reflect the redefined Address type, as shown in the following snippet:

NOTE: 

Snippet of ipo.xml using Redefined Address

 ....
 <shipTo exportCode="1" xsi:type="ipo:UKAddress">
   <name>Helen Zoe</name>
   <street>47 Eden Street</street>
   <city>Cambridge</city>
   <!-- country was added to Address which is base type of UKAddress -->
   <country>United Kingdom</country>
   <!-- postcode was added as part of UKAddress -->
   <postcode>CB1 1JR</postcode>
 </shipTo>
 ....

Our example has been carefully constructed so that the redefined Address type does not conflict in any way with the types that are derived from the original Address definition. But note that it would be very easy to create a conflict. For example, if the international address type derivations had extended Address by adding a country element, then the redefinition of Address would be adding an element of the same name to the content model of Address. It is illegal to have two elements of the same name (and in the same target namespace) but different types in a content model, and so the attempt to redefine Address would cause an error. In general, redefine does not protect you from such errors, and it should be used cautiously.