Attribute Declarations
In addition to elements, other fundamental building blocks of XML are attributes. One way to think of attributes is to imagine that elements function as nouns, and attributes are adjectives. Attributes can be used to store information that describes or modifies the information contained within an element. For example:
<phone type="office">1-800-555-1222</phone>
Here we have a phone element, which has the actual phone number as its content. However, without the type attribute, we wouldn't know whether this was a home phone, office phone, mobile phone, fax, or so on.
In this way, attributes can be very useful in XML documents, and in DTDs, attributes are declared in a manner similar to elements, using an ATTLIST declaration.
ATTLIST Declaration
An ATTLIST declaration is the physical structure in a DTD used to declare an attribute, and link it to an individual element. Because elements can have more than one attribute, the declaration is called an attribute list declaration because you can actually use it to declare more than one attribute for the same element.
ATTLIST declarations take the following form:
<!ATTLIST element
name TYPE KEYWORD>
The element is the name of the element (which must be previously declared) for which you are defining this attribute list. The name is the actual name of the attribute itself. The TYPE refers to the type of attribute that you are declaring, which we will talk about more later, and the KEYWORD is a keyword that denotes how the attribute is to function.
Attribute Types
There are a number of different types of attributes that you can declare for use with an element. The type of attribute actually refers to the type of data that an attribute contains. The vast majority of your attributes will be CDATA, or character data, which simply means that the attribute values will be treated as text. However, there are a few more types you can choose from:
ID— An ID type refers to an attribute, which is functioning as a unique ID for an element. This type will limit the acceptable value of an attribute to be a unique string for each instance of the element.
IDREF and IDREFS— If you have declared an ID type attribute for an element, you can also use IDREF and IDREFS, which are references to the ID or group of IDs.
ENTITY and ENTITIES— ENTITY and ENTITIES allow you to specify that an attribute has an entity or entities as its value.
NMTOKEN and NMTOKENS— NMTOKEN and NMTOKENS allow you to specify that an attribute has a Name Token or Name Tokens as its value.
Attributes with ENITITY or NMTOKEN values are actually pretty rare, so we won't discuss them in much detail here. However, ID attributes are more common, so let's take a look at how we might use an ID attribute.
Let's say that we had an employee file, and we wanted to have an employee ID that was unique to each employee, such as a Social Security number. We could have something that looked like this:
<employee soc="123-00-1234">John Doe</employee>
Now, if we were building a DTD to describe this structure, we would have the following element and attribute declarations:
<!ELEMENT employee (#PCDATA)> <!ATTLIST employee soc ID #REQUIRED>
This establishes our employee element, and creates the soc attribute that is functioning as an ID. Because the soc attribute is an ID, we could not have two employees with the same soc value, or the document would not be valid. ID types allow you to establish that a unique value is required for the item.
Now, say we had another element, elsewhere in the document, called payroll and we wanted a way to link the payroll element back to the original employee. Here we could use an IDREF:
<!ELEMENT payroll (#PCDATA)> <!ATTLIST payroll soc IDREF #REQUIRED>
Now, our payroll element would also have a soc attribute, but rather than serving as an ID, it would actually be treated as a reference back to the ID associated with the employee.
This type of unique ID and referencing mechanism might be somewhat familiar to you if you have worked with databases. The structures in DTDs are nowhere nearly as sophisticated as keys and unique keys in a database; however, they can be very useful. XML Schemas, however, actually add some datatypes specifically designed for mimicking the behavior of keys in databases.
Implied Versus Required
In the last few examples, you may have noticed that we have made use of the keyword #REQUIRED, which as you may have guessed, means that the attribute is required. If you use the #REQUIRED keyword with your ATTLIST declaration, when the element is used in an instance document, that attribute will be required to be used as well. If you would like an attribute to be optional, you would use the #IMPLIED keyword. For example:
<!ELEMENT employee (#PCDATA)> <!ATTLIST employee soc ID #REQUIRED dob CDATA #IMPLIED>
Here we have the soc attribute for the employee element, which is required, but we have added a dob attribute for the Data of Birth, which is optional. This means we could have either
<employee soc="123-00-1234" dob="1-29-67">John Doe</employee> <employee soc=""789-00-1234">Jane Doe</employee>
Both elements have the required soc attribute, but only the first element uses the optional dob attribute.
So, turning back to our DTD example, our seminar attendees each have a registration number, and we want that attribute to be associated with the attendee element:
<!ATTLIST attendee reg ID #REQUIRED>
Now we have an attribute called reg for the attendee element, which is required, and which will also serve as a unique identifier for each attendee.
Fixed
The final keyword that can be used with attribute declarations is #FIXED which can be used to declare an attribute that will always have a fixed value. For example:
<!ELEMENT employee (#PCDATA)>
<!ATTLIST employee
tax CDATA #FIXED "US">
This creates an attribute called tax, which will always have a fixed value of "US" for a company withholding U.S. payroll taxes. Having a fixed value does not mean that the attribute is required, just that it is assumed to have a fixed value. Because this information is stored in the DTD, when the XML document is read by a parser, the attribute will be assigned the FIXED value, present or not. For example, the following two elements are equivalent:
<employee>John Doe</employee> <employee tax="US">John Doe</employee>
Even though the attribute is not present on the first element, a parser would still have read the fixed value as "US".
Fixed attributes can be very useful for including information in XML documents that you always want present, and do not want users to be able to change, because the value is set in the DTD, not the document.
Enumerations
One of the nicest features of working with a DTD regarding attributes is the capability to specify an enumeration for the value of an attribute. An enumeration is simply a fixed list of choices for the value from which the author of the XML document must choose in order to select a correct attribute value. Enumerations are very common in computing applications, such as with pull-down menus in forms on the Web.
For example, let's say that with our seminar attendee, we want to get a phone number, but we are really interested in only an office, mobile, or fax number. So, we want to be able to specify the type of phone number collected with the phone element, using an attribute. But we want to limit the values of that attribute as well:
<!ATTLIST phone type (office | mobile | fax) "office">
This creates a type attribute, which is an enumeration. The choices for the value of the attribute are limited to the choices placed in the parentheses as shown, separated by the “|” symbol for “or.” Finally, the default value of the attribute is specified after the choices in quotation marks—in this case, our default value is "office".
Enumerations can be a great way to put flexibility into your XML documents, while still exerting some control over the value of the attributes, and you will find that appropriate places for enumerations pop up all the time.