Standards Enforcement versus Flexibility

If you are creating your documents in a structured SGML authoring environment, you might choose to use your DTD to enforce a standard structure. One way to do this is by associating specific types of document sections with specific elements.

In the previous example, you were developing a DTD for an installation and operation manual. If you want to have an enforcing DTD for this document, you might develop a DTD that requires your specific objects (or sections) to appear in a specific order (see fig. 13.1).

Fig. 13.1  An enforcing DTD.

In this example, an author using this DTD is required to include elements corresponding to each document section in the defined order. This structure can be defined down to as many levels as is required.

But suppose that you don’t want to enforce such a structure, preferring instead to allow flexibility in the content and order of the sections of a document. In that case, you might define the document model in a different way so that flexibility is permitted (see fig. 13.2).

Fig. 13.2  A flexible DTD.

In this approach, you use generic element definitions for the major document sections and the chapters within them (the elements section and chapter). You can still identify which section and chapter you’re in through the use of attributes for section and chapter names. (In fact, they’re required in this example.)

Notice that in this example, you can have sections and chapters in any order and in any combination from the choices identified in your attributes.

Maintaining Your DTD

Although this was discussed in earlier chapters, it’s necessary to stress the importance of structuring your DTD to be readable. The samples that follow illustrate this importance.

The following DTD is of the quick and dirty, unformatted school (see fig. 13.3). No extra time has been wasted on unnecessary comments, extra formatting, or organization.

Fig. 13.3  A sample DTD (unformatted).

As you glance at the preceding figure, try to relate the document elements, attributes, and so on to each other. (Then imagine that this DTD is much longer, more complex, and you haven’t looked at it in a year!)

In contrast, look at the following formatted version and see if it’s any easier to understand (see fig. 13.4).

Fig. 13.4  A sample DTD (formatted).

Notice that the formatted version is easier to read and understand. As you can see, a little formatting and alignment, coupled with descriptive comments and some white space to break things up, can make life a lot more bearable when it comes to reading and understanding DTDs.

Here’s a quick refresher course of helpful formatting tips for maintaining your DTDs:

•  Use comments generously

•  Align DTD declarations for readability

•  Use comments for section delineators

•  Group the logical sections within DTD

•  Use standard locations for entities, DTD fragments

•  Follow element definitions with related attribute lists

•  Group common model components together logically

Parsing the DTD

When you parse your DTD, you are running it by a “review committee” of sorts. The parser evaluates your DTD and gives you its verdict on whether or not the DTD is ready for production.

Similar to software compilers, parsers evaluate your DTD (and SGML document instances), ensuring that you haven’t missed any of the fundamental components.

Typical simple errors uncovered by parsing include:

•  Missing start and end tags

•  References to undefined elements

•  Invalid SGML syntax

The next section covers the role of parsers in more detail, examining their use in both the validation of DTDs and their corresponding SGML documents (i.e., specific document instances).

Parsers

In order to have an SGML document system, you must have a parser. The parser ensures that your DTD is legal according to the rules of SGML. In addition, it ensures that your SGML document instances are in conformance to the document model defined by the corresponding DTD.

Without a parser, all you really have are documents with a lot of tags. In a sense, you can think of the parser as your auditor in that it verifies that all of your SGML system components (your DTDs and SGML documents) are in accordance to the requirements specified.

Parsers can come in two forms: a limited version that does only limited checking of tags, and the more full-featured variety, called a validating parser. It’s important to understand this distinction because only a validating parser confirms that your DTDs and SGML documents are in conformance.

---

Note:  
A copy of the validating SP parser is on the CD-ROM included with this book.

---

---

• See “SP/NSGMLS Parser,” p. 490

---

What Validating Parsers Do

As previously noted, parsers are used to validate both DTDs and specific document instances. When a DTD is parsed, it is checked for conformance to the rules of SGML and “completeness.” This includes ensuring the correct use of the proper syntax (as specified in the SGML standard). It also includes a verification that elements included as content in another element’s definition are defined themselves.

The range of tasks performed by a validating parser includes a number of items. Table 13.2 lists the tasks performed by a parser when it is used to validate documents and DTDs.

Validation of document content with the document structure defined in the document’s DTD serves to ensure logical consistency.