In XML Schema, there is a basic difference between complex types, which allow elements in their content and may carry attributes, and simple types which cannot have element content and cannot carry attributes. For example, USAddress of the Purchase Order schema is complex type having five elements that are sequentially ordered and one attribute having a fixed value:

Figure: Mapping a Complex Type to a UML class

<xsd:complexType name="USAddress"> 
        <xsd:sequence> 
              <xsd:element name="name" type="xsd:string"/> 
              <xsd:element name="street" type="xsd:string"/> 
              <xsd:element name="city" type="xsd:string"/> 
              <xsd:element name="state" type="xsd:string"/> 
              <xsd:element name="zip" type="xsd:decimal"/> 
        </xsd:sequence> 
        <xsd:attribute name="country" 
                                  type="xsd:NMTOKEN" fixed="US"/> 
 </xsd:complexType>

Above table is an example of the first mapping rule:

The complex type USAddress contains five ordered elements of simple types leading to the following rules:

The above rule restricts the mapping to elements being of simple type. Complex types are mapped to associations, which are explained later on. Another mapping rule is applied to the xsd:sequence content model:

Besides elements, the USAddress type also contains an attribute that corresponds to an UML attribute:

The USAddress definition contains only declarations involving the simple types. In contrast, the PurchaseOrderType definition contains element declarations involving complex types, e.g. USAddress. The maps the PurchaseOrderType as depicted in the following table:

Figure: Mapping complex elements to UML associations

<xsd:complexType name="PurchaseOrderType"> 
        <xsd:sequence> 
              <xsd:element name="shipTo" 
                                  type="typens:USAddress"/> 
              <xsd:element name="billTo" 
                                  type="typens:USAddress"/> 
              <xsd:element ref="typens:comment" 
                                  minOccurs="0"/> 
              <xsd:element name="items" type="typens:Items"/> 
        </xsd:sequence> 
        <xsd:attribute name="orderDate" type="xsd:date"/> 
 </xsd:complexType> 
 <xsd:complexType name="USAddress"> 
        <xsd:sequence> 
              <xsd:element name="name" type="xsd:string"/> 
              <xsd:element name="street" type="xsd:string"/> 
              <xsd:element name="city" type="xsd:string"/> 
              <xsd:element name="state" type="xsd:string"/> 
              <xsd:element name="zip" type="xsd:decimal"/> 
        </xsd:sequence> 
        <xsd:attribute  name="country" type="xsd:NMTOKEN" 
                               fixed="US"/> 
 </xsd:complexType>

In defining PurchaseOrderType, two of the element declarations, for shipTo and billTo, associate different element names with the same complex type, namely USAddress. This maps nicely to UML as Figure 431 shows leading us to the next rule:

Note that the PurchaseOrderType class depicted in Figure 431 does not show any stereotypes. The reason is that in UML it is valid representation option not to display stereotypes and tagged values.

The element declarations we have described so far have each associated a name with an existing type definition. Sometimes it is preferable to use an existing element rather than declare a new element, for example:

Figure: An element refered to and its representation as UML attribute

<xsd:element ref="typens:comment" minOccurs="0"/> 

<xsd:element name="comment" type="xsd:string"/>

This declaration references an existing element, comment, which was declared elsewhere in the purchase order schema. In general, the value of the ref attribute must reference a global element, i.e. one that has been declared under xsd:schema root rather than as part of a complex type definition. The WSDL Importer resolves the element reference and thus creating an UML attribute of name comment and type String. This leads to yet another mapping rule.

Occurrence Constraints

The comment element is optional within PurchaseOrderType because the value of the minOccurs attribute in its declaration is 0. In general, an element is required to appear when the value of minOccurs is 1 or more. The maximum number of times an element may appear is determined by the value of a maxOccurs attribute in its declaration. This value may be a positive integer such as 41, or the term unbounded to indicate there is no maximum number of occurrences. The default value for both the minOccurs and the maxOccurs attributes is 1. All these XSD rules correspond to the UML multiplicity constraints. These constrainst do have the same default values and the only difference is found in the next

XSD Attributes may appear once or not at all, but no other number of times, and so the syntax for specifying occurrences of XSD attributes is different than the syntax for elements. In particular, attributes can be declared with a use attribute to indicate whether the attribute is required   (see for example, the partNum attribute declaration in PurchaseOrder schema (Figure 429)), optional  , or even   prohibited.