Stylus Studio XML Editor

Table of contents

Appendices

4.4 Deriving Complex Types by Restriction

Deriving Complex Types by Restriction

In addition to deriving new complex types by extending content models, it is possible to derive new types by restricting the content models of existing types. Restriction of complex types is conceptually the same as restriction of simple types, except that the restriction of complex types involves a type's declarations rather than the acceptable range of a simple type's values. A complex type derived by restriction is very similar to its base type, except that its declarations are more limited than the corresponding declarations in the base type. In fact, the values represented by the new type are a subset of the values represented by the base type (as is the case with restriction of simple types). In other words, an application prepared for the values of the base type would not be surprised by the values of the restricted type.

ref54 For example, suppose we want to update our definition of the list of items in an internationala purchase order so that it must contain at least one item on ordera comment; the schema shown in ipo.xsd allows an items purchaseOrder element to appear without any child item comment elements. To create our new ConfirmedItems RestrictedPurchaseOrderType type, we define the new type in the usual way, indicate that it is derived by restriction from the base type Items PurchaseOrderType , and provide a new (more restrictive) value for the minimum number of item comment element occurrences. Notice that types derived by restriction must repeat all the particle components (element declarations, model groups, and wildcards) of the base type definition that are to be included in the derived type:. However, attribute declarations do not need to be repeated in the derived type definition; in this example, RestrictedPurchaseOrderType will inherit the orderDate attribute declaration from PurchaseOrderType.

NOTE: 

Deriving ConfirmedItems by Restriction from Items Deriving RestrictedPurchaseOrderType by Restriction from PurchaseOrderType

<complexType name="ConfirmedItems">
  <complexContent>
    <restriction base="ipo:Items">
      <sequence>

         <!-- item element is different than in Items -->
         <element name="item" minOccurs="1" maxOccurs="unbounded">

         <!-- remainder of definition is same as Items -->
           <complexType>
             <sequence>
               <element name="productName" type="string"/>
               <element name="quantity">
                 <simpleType>
                   <restriction base="positiveInteger">
                     <maxExclusive value="100"/>
                   </restriction>
                 </simpleType>
               </element>
               <element name="USPrice"    type="decimal"/>
               <element ref="ipo:comment" minOccurs="0"/>
               <element name="shipDate"   type="date" minOccurs="0"/>
            </sequence>
            <attribute name="partNum" type="ipo:SKU" use="required"/>
          </complexType>
        </element>

      </sequence>
    </restriction>
  </complexContent>
</complexType>
<complexType name="RestrictedPurchaseOrderType">
  <complexContent>
    <restriction base="ipo:PurchaseOrderType">
      <sequence>
        <element name="shipTo" type="ipo:Address"/>
        <element name="billTo" type="ipo:Address"/>
        <element ref="ipo:comment" minOccurs="1"/>
        <element name="items"  type="ipo:Items"/>
      </sequence>
    </restriction>
  </complexContent>
</complexType>

This change, requiring at least one child element rather than allowing zero or more child elements, narrows the allowable number of child comment elements from a minimum of 0 to a minimum of 1. Note that all ConfirmedItems RestrictedPurchaseOrderType type elements will also be acceptable as Item PurchaseOrderType type elements.

To further illustrate restriction, Table 3 shows several examples of how element and attribute declarations within type definitions may be restricted (the table shows element syntax although the first three examples are equally valid attribute restrictions).

restrictsTable2100%examples of restriction Table 3. Restriction Examples Base Restriction(s) Notes (minOccurs, maxOccurs) (minOccurs, maxOccurs)
11 center11default="1" 11setting a default value where none was previously given
11 center11fixed="100" 11setting a fixed value where none was previously given
11 center11type="string" 11specifying a type where none was previously given
center11(0, 1) center11(0, 0) 11exclusion of an optional component; this may also be accomplished by omitting the component's declaration from the restricted type definition
center11(0, 1) center11(1, 1) 11making an optional component required
center11(0, unbounded) center11 0
center11(0, 0)
center11(0, 37)
center11(1, 37)
11
center11(1, 9) center11 0
center11(1, 8)
center11(2, 9)
center11(4, 7)
center11(3, 3)
11
center11(1, unbounded) center11 0
center11(1, 12)
center11(3, unbounded)
center11(6, 6)
11
center11(1, 1) center11(1, 1) 11cannot further restrict minOccurs or maxOccurs