9.4. Concepts and Observations Regarding Attribute Types

Attribute types have fewer options than element types, simple types, or complex types. Because of the simplicity of attribute types, this section covers only three concepts: when to use an attribute type versus an element type, global and local attribute types, and how attribute types interact with namespaces in the corresponding XML instances.

9.4.1. When to Use an Attribute Type

In many XML schemas, the use of an attribute type versus an element type is an arbitrary choice. In the following example, the customer’s ID is an attribute type:

<xsd:element name="customer"> 
    <xsd:complexType> 
        <xsd:attribute name="customerID" 
                       type="xsd:string" 
                       use="required"/> 
    </xsd:complexType> 
</xsd:element> 

Given the preceding element type, the following is valid in an XML instance:

<customer customerID="SAM132E57"/> 

Alternatively, the next example shows a customer’s ID specified as an element type:

<xsd:element name="customer"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:element name="customerID" type="xsd:string"/> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element> 

When the customer’s ID is an element type, as specified by the preceding customer, the following is valid in an XML instance:

<customer> 
    <customerID>"SAM132E57"</customerID> 
</customer> 

Neither solution is technically superior. The following list contains some guidelines to help identify good candidates for storing data in XML attributes:

• Use attribute types when the data uniquely identifies the element. The customer ID is a good example of this.

• An element may not specify multiple occurrences of an attribute.

• Attribute types specify only simple content. If the data requires nested element types—or if nested element types are likely to become a future requirement—use an element type. Element types are much more flexible. Altering the XML instance generators to add children to elements and altering the corresponding element types is much easier than conceptually recasting attribute types as element types. The schema writer should take into consideration maintenance efforts for software developers.

• Finally, and conversely, humans are more adept at reading attributes than additional elements: The number of lines in an XML instance tends to expand when elements—not attributes—contain the data. If people frequently read or validate the XML instances, the schema writer might consider using more attribute types and fewer element types.

9.4.2. Global and Local Attribute Types

Attribute types can be global or local. Typically, multiple complex types reference a global attribute type. This reference to a global attribute type can be direct via the ref attribute or indirect via a named attribute-use group. Listing 9.1 portrays the XML representation of both global and local attribute types.

9.4.3. Namespaces and Attribute Types

This section discusses how the XML instance specifies namespaces for attributes (that is, how to locate, for validation purposes, the attribute types discussed in this chapter). Chapter 3 discusses how to determine which attribute types in a schema reside in which namespace.

In an XML instance, the namespace of an attribute must match the namespace identified by the attribute type. Typically, attribute types do not specify the target namespace: Normally, the schema element specifies the target namespace. If a namespace is not specifically identified, and the target namespace is not specified, the attribute must be unqualified (that is, specified without a namespace).

In an XML instance, an attribute may be qualified (namespace specified) or unqualified (namespace not specified). An XML validator determines whether the XML instance requires a namespace by evaluating the following rules in order:

• The attribute must be appropriately qualified when the attribute type specifies a form attribute (which has a value of ‘qualified’ or ‘unqualified’).

• When the attribute type does not specify the form attribute, the attributeFormDefault attribute (which also has a value of ‘qualified’ or ‘unqualified’) of the schema element enclosing the attribute type determines whether the name of the attribute instance is qualified.

• When the attribute type does not specify the form attribute, and the schema does not specify the attributeFormDefault attribute, the attribute must be unqualified. In other words, the default value for attributeFormDefault is ‘unqualified’.

Section 9.5.1.3, along with the corresponding Listings 9.4 and 9.5, provides an example of how the form attribute of attribute types and the attributeFormDefault attribute of the schema element work.