DTDs

XML, Part 3: Document Type Definitions

Version 1.2.1¹

Hour 3: Defining XML document types: DTDs

Since XML is a meta-language, we use it for defining new languages. Our language ought to have some syntax besides just being well-formed XML (otherwise, how would MathML be different from MusicML, for example?). So, unless we're being very informal (and probably only temporarily, experimenting), we ought to define what is a valid document in this language. We can do this with a schema.

A schema specifies the structure of a valid XML document, much like a database table schema specifies the structure of the table.

There are at least three kinds of schemas:

• Document Type Definitions (DTDs)
• XML Schema Definitions (XSDs)
• RELAX NG schemas

In this "hour", we focus on DTDs, which are the earliest form, inherited from SGML. While DTDs are less powerful than the other two kinds, the are useful to know because:

• They suffice for simple markup languages.
• They have been around a long time and are still in use. They are sometimes the only documentation describing the markup language they define. In short, they are "legacy" schemas.

Schemas provide more than just documentation, however: they allow documents to be rigorously validated.

DTD Declarations

A DTD specifies the types of elements and attributes that may occur in a document, and how they are structured.

Element Declarations

• Form: <!ELEMENT ElementName ElementType>
• Element types
  • EMPTY
  • Element-only (child elements): you should know the meanings of these symbols; they are widely used, and not only in DTDs:
    • Combining elements:
      • () grouping
      • , seqence
      • | or
      • If you use both , and |, then you must use parentheses for grouping, because there is no implicit order of precedence between them.
    • Number (cardinality constraints):
      • ? zero or one
      • * zero or more
      • + one or more
      • (no symbol) exactly one
  • Mixed (elements and character data)
    • #PCDATA means parsed character data
      • Parsed means whitespace reduction and (I think) entity processing (we cover entities in a later chapter).
    • CDATA means unparsed character data (more on this later)
    • Curious rule (p. 60): #PCDATA must come first in a choice group and the group must be "zero or more", like this: (#PCDATA | somethingelse)*
      • This is too complicated! If something is too complicated to be expressed easily as a DTD, then maybe we should use another type of schema, such as XSD.
  • Any (anything at all)

Attribute Declarations

• Form: <!ATTLIST ElementName AttributeName AttributeType AttributeDefault ... >
• Attribute types (p. 62)—there are 10 types, but for the time being, we only need to be concerned with the first two:
  • CDATA (unparsed character data)
  • Enumerated, e.g., (small | medium | large)
• Attribute default declarations (p. 61):
  • #REQUIRED (required)
  • #IMPLIED (optional, i.e., not required—strange choice of word)
  • #FIXED value (e.g., #FIXED 10, or maybe #FIXED "10")
  • Default (e.g., "10")

Design Issues: Elements or Attributes?

When designing a document schema, it is not always obvious whether to treat something as an element or as an attribute. Indeed, in many cases, one way is not necessarily right and the other way wrong.

But here are some suggestions.

Key differences:

• Elements allow substructure (child elements or content); attributes do not. This suggests that atomic data are better modeled as attributes, and non-atomic data as elements.
• Attributes can be more constrained (by DTDs; this does not apply so much to XSDs).
  • Enumerated types
  • Default values
• Attributes are limited to short strings (???)
• "Extra" whitespace is significant in attribute values (it is CDATA, not #PCDATA).

The author suggests that constraining the data as much as possible is desirable—why?—and consequently recommends using attributes whenever possible. But remember this advantage occurs if we use DTDs, but not with XSDs.

My recommendation would be: usually, if it's atomic data, use an attribute; if it's not, you must use an element. (Well, you could force it to be an attribute, but then you'd be giving up much of the value of using XML.)

Attaching a DTD to a Document

A document should usually say what schema it's intended to conform to. For DTDs, this is done with the !DOCTYPE declaration, just below the XML declaration (pp. 51, 52, 53).

Validating a Document with an Attached DTD

If FILE is "attached" to a document by a !DOCTYPE declaration, then

$ xmllint --noout --valid FILE

will check for errors against the DTD, as well as being well-formed XML.

Discussion

• Explain the etml.dtd in Listing 3.3
• Explain the ETML document in Listing 3.4

Exercises

Page 69, #1 and 2.

If there is more time, consider some ways of representing the following database tables in XML, using flat and nested designs. (Nested: product within distributor, or vice-versa; flat: using the attribute types ID, IDREF, and IDREFS.)

Product table:

Distributor table:

Product-Distributor table: