In What Environment Will It Be Used? With the growth of the Internet, many organizations are rushing to provide an electronic delivery of information to their customers, members, supporters, and so on. As they go through the process of preparing information for electronic delivery, providers are discovering that many of their existing notions (derived from their experience with hardcopy document preparation) need to be rethought.

Even if you are preparing a class of documents for hardcopy delivery only, you might want to stop and reflect, “Might I want to someday use this document in a different environment?” Chances are, if you will be using these documents for several years, the answer just might be yes.

Planning for electronic delivery (either now or in the future) can impact some important facets of your DTD (and document) design.

Electronic delivery systems, such as the Internet and electronic books on CD-ROM, have brought a new emphasis to non-linear navigation approaches. Through the use of hyperlinked references, for example, readers can take a path through a document (or collection) that was completely unanticipated by the document authors.

This method of traversing related data can greatly emphasize the importance of indexing links in documents and collections.

Document Lifespan

How long you will use and maintain your SGML documents (or the information within them) plays an important role in your DTD-based document model. Earlier in this book, you learned that a long-lived document might start in a hardcopy format and change to an electronic one later.

The DTDs that you use and maintain for a long period of time might go through a long series of modifications, enhancements, and additions. In those circumstances, a highly flexible arrangement in your DTD will likely become a high priority.

Sanity Checking Your DTD

No matter how good your DTD looks, it always helps to perform sanity checking before you put it into production. By doing this, you confirm that your assumptions within the DTD are correct and in line with the concepts of others involved in the documents and the steps in their production.

Sanity checking can take two forms:

•  Validating the DTD concept (the document model) with people familiar with what the document is supposed to do

•  Comparing the DTD document model against various versions of the document type

Does the DTD Content Model Match Other People’s Expectations? In many situations, it can be helpful to validate your DTD by comparing its concept of the document model with the concept of others. For example, if you are going to convert an existing class of operations manuals to SGML, you might want to meet with a number of people throughout your organization who are familiar with these documents.

When you compare the concept of the document (as modeled in the DTD) with others, it really doesn’t matter if they are not familiar with SGML. What does matter is that they are familiar with the document that you’re modeling. When that is the case, these individuals can often provide invaluable insights on a type of document that might vary quite a bit across its various examples.

Take a look at a specific example. Imagine that you’re in the process of writing a DTD for an installation and operation manual for your company. In it, you will have a standard approach for handling both types of actions (installation and operation) of various products that your company produces. Although your company produces a variety of products, the operations manuals are pretty similar across product lines. In the process of document analysis, you determine that these manuals contain the specific sections in the following order:

I.  Introduction

II.  Safety Notes

III.  Installation

A.  Component Assembly

B.  Component Installation

C.  Component Checkout

D.  Package Checkout

IV.  Operation

A.  Overview

B.  Controls

C.  Operation

D.  Shutdown

E.  Maintenance

After developing a DTD that reflects this structure, you proceed to your validation and meet with people to confirm your document model. When doing so, you might want to confirm that your DTD passes the following tests.

Does your DTD work for:

•  A simple version of the document?

•  A complex version of the document?

•  An oddball version of the document?

As you work with your group, you might run across some variance in the range of possible ingredients in your “standard” document type. Your DTD might work well for simple versions of the document, for example. Users might suggest a simple version: “Check the Lemur 100, it has all of the basic parts but no options.” However, complicated examples might not fit into your document model: “…But the Okapi 9750 has 26 options to be covered.”

In other cases, oddball versions of your document might not fit. As you explore various types of installation and operation manuals, you might encounter observations like “It’s always in that order, except for the Wombat 2000 model. In that case, we make ‘package checkout’ a major section and put it last.”

The question of detail in your document model is often worth exploring at this point. Compare your range of document samples with your DTD and ask some questions: Does your DTD include the right amount of detail in its document model? In some cases, you might want to model generic sections in your document. In others, you might want to require specific named document sections in a specific order to enforce a standard document format.