Table of contents
Appendices
|
4.4 Deriving Complex Types by RestrictionDeriving 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
| 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 |
(minOccurs, maxOccurs)
(minOccurs, maxOccurs)
| 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 |
|