Special Edition Using SGML:Following Good SGML Practice

How Flexible Should DTDs Be?

The nice thing about DTDs is that they can keep a group of writers from being too creative. However, DTDs are flexible enough to allow for creative change and innovation. You select the range of flexibility that you want your DTD(s) to permit.

• See “Decide What Standards and Policies You Must Obey,” p. 112

In the environment definition part, you determine whether any standards need to be followed. If there are standards, such as ATA 100, you should incorporate that much rigidity into your DTDs. That way, your writers will not get so creative that they neglect conforming to the standards.

Tip:
The main question to ask is what can change more easily in your situation—the document structure or the DTD?

Before you can answer whether the document or the DTD is easier to change, you must have as large a sample of documents as you can manage. You must be sure that the structure for your document type is consistently represented in your DTD. Then, if you need to keep a fairly loose structure, you can build that flexibility into the DTD. Or, if you must follow a strict structure, as in a military technical manual, you can build rigidity into the DTD. In either case, you must have a clear picture of the document’s structure from a large sample of documents of that type.

Then, as for determining whether to change the document or the DTD, it depends on which can be more flexible. After looking at a large sample of documents, you might decide that your technical manuals do have various structures. For example, you might observe that some technical manuals have complicated tables and equations while others have none. Build the flexibility into your DTD and allow your writers to be more creative.

On the other hand, if your technical manuals must follow a rigid form, build that strictness into your DTD. The basic questions you should ask are:

• Should the DTD enforce rules?

• Can document structures still be changed for the sake of SGML rules without compromising other rules that must be followed?

• Can SGML rules be adapted to accommodate your unique application?

• Do you know enough about your document instances to accurately specify content models?

The question of how rigid to make your DTDs is a highly individual one. The answer depends on many factors specific to you and your installation. Here are some examples:

    <!ELEMENT strict  - - (a,b,c,d)               >
    <!ELEMENT medium  - - (a|b|c)+,(d|e)+         >
    <!ELEMENT wildthing - - (a|b|c|d|e|f)*        >

Most likely, SGML can accommodate your most constrictive scenario or your most indulgent scenario—possibly even both. That’s the advantage of using an international standard. It has already done a lot of adapting.

Miscellaneous Reminders

If you observe the precautions discussed in this chapter in your DTD design, you go a long way toward writing clean and workable applications. Here are a few more rules you should try to follow. They are mostly common sense.

Processing Instructions

This is one practice that you should try to avoid, but that you will probably find irresistible. The problem with processing instructions is that they are different for each system that must do the processing. Therefore, whenever you include these instructions, you must make them fit the machine that executes them. But, whenever you do that, you make your document less transportable. The idea behind SGML is to make your document more standardized with generic markup. If you include processing instructions, your document is no longer generic.

In SGML, marked sections are a convenient place to use processing instructions, when you must use them. Within the marked sections, you can include the specific instructions within parameter entities. That way, when you must change the processing instructions to fit another system, you can change the values of the parameter entities to do so. For example:

    <![ IGNORE [<?.cc 10>]]>

shows the marked section and the processing instruction for TeX. You can make an entity declaration in the DTD that can define a processing system, such as TeX. For example:

    <!ENTITY % tex "IGNORE">

For the TeX processing system, you can use something like the following in your document for TeX commands:

    <![ %tex; [
    <!ENTITY newpage "<?\newpage>">
    ]]>

You can include as many TeX commands as necessary and make each one an entity. If you need another processing system, use it within another marked section and declare another entity for that particular processing system. Instead of changing each processing system command, change the values of the entities. That saves a lot of work.

• See “External Processing of Equations,” p. 425

Note:
You’ll notice another way of invoking the TeX equation editor system in “The NOTATION Declaration” section in Chapter 16. The procedure above using parameter entities is simply one more approach to using processing instructions with TeX as an example.
Remember: The more you use processing instructions, the more you compromise your generic markup. It’s far better if you stick to the output specification and stylesheet scenario for designing the final product output.

Table of Contents