Complex Content
A complex type specifies nested elements via complex content. Complex content provides for the validation for an XML element hierarchy. There are four elements for specifying nested content: sequence, choice, all, and group.
The sequence element type
The sequence element supports an XML representation of an ordered set of element types. For each element type associated with a sequence element in an XML schema document, there must be an element in the XML instance, in the same order. In fact, there may be zero or many elements for each element type, depending on the values of the minOccurs and maxOccurs attributes associated with the element types.
The next example specifies a customer's address, which must be in the standard postal address order:
<xsd:complexType name="addressType"> <xsd:sequence> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="country" type="xsd:string" fixed="US"/> <xsd:element name="zip" type="xsd:string"/> </xsd:sequence> <xsd:attribute name="zipPlus4" use="optional"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="[0-9]{5}-[0-9]{4}"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:complexType>
An element type whose structure type is addressType might look like the following element:
<xsd:element name="address" type="addressType"/>
Given the preceding element type, the following element is valid in an XML instance:
<address zipPlus4="12345-6789"> <street>123 A Street</street> <city>Megaopolis</city> <state>OR</state> <country>US</country> <zip>12345</zip> </address>
The choice element type
The choice element supports an XML representation for describing a selection from a set of element types. An XML instance contains elements whose element types are the set specified by the choice element in an XML schema document. The minOccurs and maxOccurs attributes might permit the XML instance to select several (for example, between two and four) occurrences of element types from the set.
For this example, suppose that a catalog supports computers. A computer can be a laptop, desktop, or server. Each of these has options that are not described in this document:
<xsd:complexType name="computerType"> <xsd:choice> <xsd:element name="laptop" type="laptopType"/> <xsd:element name="desktop" type="desktopType"/> <xsd:element name="server" type="serverType"/> </xsd:choice> </xsd:complexType>
An element type whose structure type is computerType might look like the following element:
<xsd:element name="computer" type="computerType"/>
Given the preceding element type, the following element is valid in an XML instance:
<computer> <laptop> * * * * * </laptop> </computer>
The all element type
The all element specifies an unordered set of element types. For each element type associated with an all element in an XML schema document, there must be an element in the XML instance. However, they may appear in any order. In fact, there may be zero or many elements for each type, depending on the values of the minOccurs and maxOccurs attributes associated with the appropriate element type.
The next element specifies part options. The part options are color and size, which can appear in any order:
<xsd:complexType name="partOptionType"> <xsd:all> <xsd:element name="color" type="xsd:token"/> <xsd:element name="size" type="xsd:token" minOccurs="0"/> </xsd:all> </xsd:complexType>
An element type whose structure type is partOptionType might look like the following element:
<xsd:element name="partOption" type="partOptionType"/>
Given the preceding element type, the following element is valid in an XML instance:
<partOption> <size>big</size> <color>aquamarine</color> <partOption>
The group element type
The group element describes a named model group. A named model group encapsulates an all element, a choice element, or a sequence element. When a complex type incorporates a named model group (via the ref attribute), the scope of the corresponding element types change: the namespace for the element types becomes local to the parent element type. Note that there might be many different parent element types when the complex type incorporating the named model group is also global: the complex type might be the structure type of multiple element types.
The next element is a named model group that supports multiple pricing models. The idea is that normal full price items require only a price; a sale item requires a price and an authorization; a clearance item requires a price and a manager's authorization; and a free item does not specify a price, but requires a manager's authorization (The example schema details the various complex types specifying the prices):
<xsd:group name="priceGroup"> <xsd:choice> <xsd:element name="fullPrice" type="fullPriceType"/> <xsd:element name="salePrice" type="salePriceType"/> <xsd:element name="clearancePrice" type="clearancePriceType"/> <xsd:element name="freePrice" type="freePriceType"/> </xsd:choice> </xsd:group>
A group provides the flexibility of reusing an entire complex type: in this case a choice of pricing models. The next element is a complex type that specifies a reference to this pricing group:
<xsd:complexType name="computer"> <xsd:sequence> <xsd:element name="style"> <xsd:complexType> <xsd:choice> <xsd:element name="laptop" type="laptopType"/> <xsd:element name="desktop" type="desktopType"/> <xsd:element name="server" type="serverType"/> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:group ref="priceGroup"/> </xsd:sequence> </xsd:complexType>
An element type whose structure type is computerType might look like the following element:
<xsd:element name="computer" type="computerType"/>
Ultimately, an element in a corresponding XML instance must specify the computer's style, as well as some sort of price specification. Given the preceding element type, the following element is valid in an XML instance:
<computer> <style> <laptop> * * * * * </laptop> </style> <salePrice authorization="frank">3.20</salePrice> </computer >