</xsd:restriction>
</xsd:simpleType>
Complex Types
In XML Schema, simple types define the valid choices for character-based content such as attribute values and elements with character content. Complex types
g
, on the other hand, define complex content models, such as those of elements that can have attributes and nested children. Complex type definitions address both the sequencing and multi-plicity of child elements as well as the names of associated attributes and whether they’re required or optional.The syntax for defining complex types is straightforward:
<xsd:complexType name=”typeName”>
<xsd:someTopLevelModelGroup>
<!-- Sequencing and multiplicity constraints for child elements defined using xsd:element -->
</xsd:someTopLevelModelGroup>
<!-- Attribute declarations using xsd:attribute -->
</xsd:complexType>
The element xsd:complexTypeidentifies the type definition.There are many different ways to specify the model group of the complex type.The most commonly used top-level model group elements you’ll see are
n xsd:sequence—A sequence of elements
n xsd:choice—Allows one out of a number of elements
n xsd:all—Allows a certain set of elements to appear once or not at all but in any order
n xsd:group—References a model group that is defined someplace else
These could be further nested to create more complex model groups.The xsd:group model group element is covered later in this chapter in the section “Content Model Groups.”
Inside the model group specification, child elements are defined using xsd:element. The model group specification is followed by any number of attribute definitions using
xsd:attribute.
For example, one possible way to define the content model of the PO address used in thebillToandshipToelements is shown in Listing 2.15.The name of the complex type is addressType. Usingxsd:sequenceandxsd:element, it defines a sequence of the elements name,company,street,city,state,postalCode, andcountry.
Listing 2.15 Schema Fragment for the Address Complex Type
<xsd:complexType name=”addressType”>
<xsd:sequence>
<xsd:element name=”name” type=”xsd:string” minOccurs=”0”/>
<xsd:element name=”company” type=”xsd:string” minOccurs=”0”/>
<xsd:element name=”street” type=”xsd:string”
maxOccurs=”unbounded”/>
<xsd:element name=”city” type=”xsd:string”/>
<xsd:element name=”state” type=”xsd:string” minOccurs=”0”/>
<xsd:element name=”postalCode” type=”xsd:string”
minOccurs=”0”/>
<xsd:element name=”country” type=”xsd:string” minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id” type=”xsd:ID”/>
<xsd:attribute name=”href” type=”xsd:IDREF”/>
</xsd:complexType>
The multiplicities of these elements’ occurrences are defined using the minOccursand
maxOccursattributes of xsd:element.The value of zero for minOccursrenders an ele-ment’s presence optional (?in the document structure diagrams).The default value for
minOccursis 1.The special maxOccursvalue“unbounded”is used for the street ele-ment to indicate that at least one must be present (+in the document structure dia-grams).
61 XML Schemas
As we mentioned earlier, every element is associated with a type using the type attribute xsd:element. In this example, all elements have simple character content of typestring, identified by the xsd:stringtype. It might seem unusual that the name-space prefix is used inside an attribute value. It’s true, the XML Namename-spaces specification doesn’t explicitly address this use of namespace prefixes. However, the idea is simple. A schema can define any number of types. Some of them are built into the specification, and others are user-defined.The only way to know for sure which type is being referred to is to associate the type name with the namespace from which it’s coming.What better way to do this than to prefix all references to the type with a namespace prefix?
After the model group definition come the attribute definitions. In this example,
xsd:attributedefines attributes idandhrefof types IDandIDREF, respectively. Both attributes are optional by default.
Now, consider a slightly more complex example of a complex type definition—the
poelement’s type (see Listing 2.16).
Listing 2.16 Schema Fragment for the Purchase Order Complex Type
<xsd:complexType name=”poType”>
<xsd:sequence>
<xsd:element name=”billTo” type=”addressType”/>
<xsd:element name=”shipTo” type=”addressType”/>
<xsd:element name=”order”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name=”item” type=”itemType”
maxOccurs=”unbounded”/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=”id” use=”required”
type=”xsd:positiveInteger”/>
<xsd:attribute name=”submitted” use=”required”
type=”xsd:date”/>
<xsd:attribute name=”customerId” use=”required”
type=”xsd:positiveInteger”/>
</xsd:complexType>
ThepoTypeintroduces three interesting aspects of schemas:
n It shows how easy it is to achieve basic reusability of types. Both the billToand
shipToelements refer to the addressTypedefined previously. Note that because this is a user-defined complex type, a namespace prefix isn’t necessary.
n The association between elements and their types can be implicit.The order ele-ment’s type is defined inline as a sequence of one or more itemelements of type
itemType.This is convenient because it keeps the schema more readable and pre-vents the need to define a global type that is used in only one place.
n The presence of attributes can be required through the use=”required” attribute-value pair of the xsd:attributeelement.To give default and fixed values to attributes, you can also use the aptly named defaultandfixedattributes of
xsd:attribute.