The bulk of the DTD is composed of ELEMENT definitions (covered in this section) and ATTRIBUTE definitions (covered in the next). An element definition begins with the ELEMENT keyword, following the standard <! opening of a DTD tag, and then the name of the element. Following that name is the content model of the element. The content model is generally within parentheses, and specifies what content can be included within the element. Take the book element as an example:

Of course, in many cases you need to specify multiple occurrences of an element, or optional occurrences. You can do this using the recurrence modifiers listed in Table 2-1.

If an element has character data within it, the #PCDATA keyword is used as its content model:

If an element should always be an empty element, the EMPTY keyword is used:

Once you've handled the element definition, you'll want to define attributes. These are defined through the ATTLIST keyword. The first value is the name of the element, and then you have various attributes defined. Those definitions involve giving the name of the attribute, the type of attribute, and then whether the attribute is required or implied (which means it is not required, essentially). Most attributes with textual values will simply be of the type CDATA, as shown here:

You can specify entity reference resolution in a DTD using the ENTITY keyword. This works a lot like the DOCTYPE reference I talked about earlier, where a public ID and/or system ID may be specified. In the example DTD, I've specified a system ID, a URL, for the OReillyCopyright entity reference to resolve to:

Now this is hardly an extensive reference on DTDs, but it should give you enough basic knowledge to get going. As I've suggested, have some additional resources specifically on XML available (like XML in a Nutshell) as you go through this book in case you run across something you're unsure about. By assuming that you have that or the online specifications from http://www.w3.org around, I can delve into Java topics more quickly.

Elements are defined with the element construct. You'll generally need to define your own data types by nesting a complexType tag within the element element, which defines the name of the element (through the name attribute). Take a look at this fragment of Example 2-4:

<xs:element name="book">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="title" />
      <xs:element ref="contents" />
      <xs:element ref="ora:copyright" />
    </xs:sequence>
  </xs:complexType>
</xs:element>

Here, I've specified that the book element has complex content. Within it there should be three elements: title, contents, and ora:copyright. By using the sequence construct, I've ensured that they appear in the specified order; and with no modifiers, an element must appear once and only once. For each of these other elements, I've used the ref keyword to reference another element definition. This points to the definitions for each of these elements in another part of the schema, and keeps things organized and easy to follow.

Later in the file, the title element is defined:

<xs:element name="title">
  <xs:complexType>
    <xs:simpleContent>
      <xs:restriction base="xs:string">
        <xs:attribute ref="ora:series" use="required" />
      </xs:restriction>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

This element is really just a simple XML Schema string type; however, I've added an attribute to it, so I must define a complexType. Since I'm extending an existing type, I use the simpleContent and restriction keywords (as nested elements) to define this type. simpleContent informs the schema that this is a basic type, and restriction, with the base of "xs:string", lets the schema know I want to allow just what the XML Schema string type allows, plus the additional attribute defined here (with the attribute keyword). For the attribute itself, I reference the type defined elsewhere, and specify that it must appear for this element (through use="required"). I realize that this paragraph is a mouthful, and not completely obvious; however, take your time and you'll get it all.

One other thing you'll notice is the use of minOccurs and maxOccurs attributes on the element element; these attributes allow an element to appear a specified number of times other than the default, which is once and only once. For example, specifying minOccurs="0" and maxOccurs="1" allows an element to appear once, or not at all. To allow an element to appear an unlimited number of times, you can use the value of "unbounded" for the maxOccurs attribute, as in Example 2-4.

This essentially says for the namespace http://www.oreilly.com/javaxml2, look up definitions in the schema called contents.xsd in the XSD/ directory. For the http://www.oreilly.com namespace, use the contents-ora.xsd schema in the same directory. You'll then need to define the two schemas I showed you in Example 2-5 and Example 2-5. Finally, import the O'Reilly schema into the Java and XML one, since elements in the Java and XML schema refer to attributes in the O'Reilly one:

<xs:import namespace="http://www.oreilly.com" 
           schemaLocation="contents-ora.xsd" />

This import is fairly self-explanatory, so I won't dwell on it. You should realize that dealing with multiple namespaces is about the most complex thing you can do in schemas, and can easily trip you up. (It tripped me up, until Eric van der Vlist saved the day.) I also recommend a good XML Schema-capable editor. While I'm generally slow to recommend commercial products, in this case XMLSpy 4.0 (http://www.xmlspy.com) turned out to be wonderfully helpful.

I've barely scratched the surface of either DTDs or XML Schema, and there are even other constraint models not covered at all! For example, Relax (and Relax NG, which includes what used to be TREX) is gaining a lot of steam, as it's considered a lot easier and more lightweight than XML Schema. You can check out the activity online at http://www.oasis-open.org/committees/relax-ng/. No matter what technology you choose, though, you should be able to find something that helps you constrain your XML documents. With these constraints in place, validation and interoperability become a snap. Consider yourself educated on XML constraints, and get ready to move on to the next topic in this whirlwind tour: XML transformations.