Chapter: XML and Web Services : Essentials of XML : Validating XML with the Document Type Definition (DTD)

DTD Attributes and its Types

XML attributes are name/value pairs that are used as metadata to describe XML ele-ments. XML attributes are very similar to HTML attributes. In HTML, src is an attribute of the img tag, as shown in the following example:

DTD Attributes

So far you have seen that it is possible to use intricate combinations of elements and symbols to create complex element definitions. Now let’s take a look at how XML attribute definitions can be added into this mix.

In this example, width and height are also attributes of the img tag. This is very similar to the markup in Listing 3.12, which demonstrates how an image element might be struc-tured in XML.

LISTING 3.12 Attribute Use in XML

<image src=”images/” width=”10” height=”20”> imagename.gif

</image>

In Listing 3.12, src, width, and height are presented as attributes of the XML element image. This is very similar to the way that these attributes are used in HTML. The only difference is that the src attribute merely contains the relative path of the image’s direc-tory and not the actual name of the image file.

In Listing 3.12, the attributes width, height, and src are used as metadata to describe certain aspects of the content of the image element. This is consistent with the normal use of attributes. Attributes can also be used to provide additional information to further identify or index an element or even give formatting information.

Attributes are also defined in DTDs. Attribute definitions are declared using the ATTLIST declaration. An ATTLIST declaration will define one or more attributes for the element that it is referencing.

Attribute list declarations in a DTD will have the following syntax:

<!ATTLIST elementname attributename type defaultbehavior defaultvalue>

ATTLIST is the tag name that specifies that this definition will be for an attribute list.

elementname is the name of the element that the attribute will be attached to.

attributename is the actual name of the attribute.

type indicates which of the 10 valid kinds of attributes this attribute definition will

be.

• defaultbehavior dictates whether the attribute will be required, optional, or fixed in value. This setting determines how a validating parser should relate to this attribute.

• defaultvalue is the value of the attribute if no value is explicitly set.

Take a look at Listing 3.13 for an example of how this declaration may be used.

LISTING 3.13 ATTLIST Declaration

<!ATTLIST name

sex CDATA #REQUIRED age CDATA #IMPLIED race CDATA #IMPLIED >

In Listing 3.13, an attribute list is declared. The name element is being referenced by the declaration. Three attributes are defined; sex, age, and race. The three attributes are character data (CDATA). Only one of the attributes, sex, is required (#REQUIRED). The other two attributes, age and race, are optional (#IMPLIED). An XML element using the attribute list declared here would appear as follows:

<name sex=”male” age=”30” race=”Caucasian”>Michael Qualls</name>

The name element contains the value “Michael Qualls”. It also has three attributes of Michael Qualls: sex, age, and race. The attributes in Listing 3.13 are all character data (CDATA). However, attributes actually have 10 possible data types.

Attribute Types

Before going over a more detailed example of using attributes in your DTDs, let’s first review Table 3.2, which presents the 10 valid types of attributes that may be used in a DTD. Then we will look at Table 3.3, which shows the default values for attributes.

You saw during the coverage of the 10 valid attribute types that we used two preset default behavior settings: #REQUIRED and #IMPLIED. There are four different default types that may be used in an attribute definition, as detailed in Table 3.3.

So far you have element (ELEMENT) declarations and attribute (ATTLIST) declarations under your belt. You have seen that you can create some very complex hierarchical struc-tures using elements and attributes. Next, we will take a look at a way to save some time when building DTDs. DTD entities offer a way to store repetitive or large chunks of data for quick reference. First, however, we are going to revisit our mini case study.

Zippy Human Resources: XML for Employee Records, Part II

This is the second part of our mini case study on the use of XML in the Human Resources department at Zippy Delivery Service. You saw in Part I that the Human Resources department was able to put together a DTD (Employees1. dtd) and an XML document with some employee records (Employees1.xml). The DTD was referenced from the XML file for purposes of validation.

Upon review of their DTD, the members of the Human Resources department have decided that they are not quite satisfied. They feel that they have two types of information about each employee: personal information and contact information. They’ve decided that the personal information would be better stored as attributes of the employee name element rather than as individual ele-ments. Additionally, they’ve decided that they need an ID type of attribute for each employee element in order to be able to quickly search the XML document. The DTD, therefore, has been amended as follows (you can download the DTD Employees2.dtd from the Sams Web site):

<!ELEMENT employees (employee+) >

<!ELEMENT employee (name, position, address1, address2?, city, state, zip, phone?, email?) >

<!ATTLIST employee serial ID #REQUIRED > <!ELEMENT name (#PCDATA) >

<!ATTLIST name

age CDATA #REQUIRED sex CDATA #REQUIRED race CDATA #IMPLIED

m_status CDATA #REQUIRED >

<!ELEMENT position (#PCDATA) >

<!ELEMENT address1 (#PCDATA) >

<!ELEMENT address2 (#PCDATA) >

<!ELEMENT city (#PCDATA) >

<!ELEMENT state (#PCDATA) >

<!ELEMENT zip (#PCDATA) >

<!ELEMENT phone (#PCDATA) >

<!ELEMENT email (#PCDATA) >

You can see that a new ID attribute, serial, has been added for the employee element. The serial attribute is marked as required (#REQUIRED). The age, sex, race, and m_status elements have been removed and changed to attributes of the name element. Each of these attributes is character data (CDATA). Also, the race attribute has been deemed optional (#IMPLIED).

The XML document has also been updated to reflect the new requirements of the changed DTD (you can download XML document Employees2.xml from the Sams Web site):

<?xml version=”1.0”?>

<!DOCTYPE employees SYSTEM “employees2.dtd”>

<name age=”37” sex=”Male” race=”African American” m_status=”Married”> Bob Jones

</name>

<position>Dispatcher</position> <address1>202 Carolina St.</address1>

<city>Oklahoma City</city> <state>OK</state> <zip>73114</zip> <phone>4055554321</phone> <email>bobjones@mail.com</email> </employee>

<name age=”19” sex=”Female” race=”Caucasian” m_status=”Single”> Mary Parks

</name>

<position>Delivery Person</position> <address1>1015 Empire Blvd.</address1> <address2>Apt. D3</address2> <city>Oklahoma City</city> <state>OK</state>

<email>maryparks@mail.com</email>

</employee>

<name age=”23” sex=”Male” race=”African American” m_status=”Single”> Jimmy Griffin

</name>

<position>Delivery Person</position> <address1>1720 Maple St.</address1> <city>Oklahoma City</city> <state>OK</state>

</employee>

</employees>

In order for the XML document to remain valid according to the DTD, a serial attribute has been added for each employee element. Each serial attribute is set to a unique value. The age, sex, race, and m_status elements have been removed and added as attributes of the name element.

The Zippy Human Resources department now feels that they are getting pretty close to having the DTD and XML structure they need in order to have an effective solution for storing their employee records. However, as you’ll see in Part III, there is still a bit more tweaking that can be done with the addition of entities.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

XML and Web Services : Essentials of XML : Validating XML with the Document Type Definition (DTD) : DTD Attributes and its Types |