Chapter 11
Using DTD Components

As you saw in the previous chapter, defining a DTD can get rather involved because of all the elements, attributes, and entities that can be included in a complex document. If your head is spinning as you consider the possibilities involved in defining every object—chapters, sections, paragraphs, bulleted lists, and so on—don’t worry.

Although SGML requires that the objects in a DTD be defined, it provides much flexibility in how to do it. It is usually possible to define the objects in a document only once and to reference them later as they are needed. This approach reduces the effort required to modify document models. It ensures a common approach to standard document components and provides for a common “look” across your document library.

This chapter examines reusable document components. You learn how to:

•  Use reusable document components

•  Use fragment DTDs

•  Use DTD redefinition

•  Create elements by means of parameter entities

You will examine the various methods of using modular DTD components and look at a few examples. When you complete this chapter, you will be able to modularize your document type definitions so that you can reuse the portions that are common across various document types.

---

Tip:  
If you intend to use standard DTDs off the shelf with only minor modifications, modular techniques can greatly simplify your efforts.

---

When (and Why) To Use DTD Components

You might find that using DTD components often helps in reducing clutter—for example, when you start with a few simple DTDs but expect that you will need to add additional definitions of new document types over time.

It might be helpful to think of DTD components as types of tools, such as those you might use in a home shop. If you were going to build window frames, you would probably construct a few tools to make common parts of the window production process easier.

Similarly, the construction and maintenance of DTDs usually involves shared document elements. When you expect this to be the case, why not spend a little time up front constructing a DTD module that you can use repeatedly? To get an idea whether you should use modular DTDs, refer to the checklist in table 11.1. In general, if any of these issues apply to your DTDs, you should consider using modular DTD components.

Multiple DTDs

As you begin developing your SGML document environment, ask yourself, “Will this be something that grows? Will I have many document types before I am done?” If the answer is Yes—or even if multiple, related document types are a possibility—dividing your DTDs into modules could pay great dividends in the long term.

It might take a little extra time in the beginning, but you will save time and effort over the lifetime of your SGML document library if you can reuse modules that your documents share. Those modules can be, for example, section or chapter definitions, or more specialized objects such as product descriptions. In any case, modular DTDs enable you to reuse both document definitions and the actual contents of SGML documents.

Many Developers

Many people are often involved in developing an SGML document system. Projects often depend on the help of outside consultants, who guide the initial document development. These consultants help educate the participants of a project in the basics of SGML development, and they facilitate the process of designing and constructing SGML DTDs.

After the initial efforts are under way, additional document types might be added to the SGML collection. New developers might join the team to help construct other documents, which will be added as the SGML project progresses.

When new developers come in, they must come up to speed on the existing document environment. If they are fairly new to SGML, they must cope with the intricacies of the language while they become familiar with the existing document types. A modular DTD environment can help. Developers can learn the SGML syntax by examining a shared document structure defined in reusable DTD components.

A Growing DTD Environment

As you go through the DTD process, you might find yourself adding more document types to your SGML collection. Each new type of document, of course, requires the development of its own DTD.

Developing DTDs can be a slow process at first, as you painstakingly examine all the detail involved in the document that you are modeling. In the early stages of SGML implementation, you might find it painful to examine all the objects that a document can contain—chapters, sections, paragraphs, tables, lists, graphics, and so on. As you develop more DTDs, however, the process gets easier.

When you are using DTD modules, you might find yourself looking at a new document type with a form of mental shorthand. That is, you visualize the new document model in your head and say, “How does the bulk of this one differ from what has come before? How much of it is the same?”

In many situations, the answer is that much of it is the same. Although documents can be rich in their complexity, the basic building blocks are often repeated. Many companies have documents that share key aspects of how they are put together. The same group of people are often involved in creating or writing several types of documents. Therefore, they bring the same perspective to all the documents that they create. From this type of situation, a range of documents that have a similar style may evolve. With a modular document component structure, an organization can make a more conscious effort to encourage a common look across collections of documents.

In short, with reusable document components, you can manage the growth phase as you add new document types to your SGML document universe.