Structure Standards

The most crucial standard, document structure, is tricky because it’s abstract and hard to differentiate between it and content and format. Structure gets into the heart of what the document is. Your DTDs will define the structure of each of your document types. They will be a blueprint for your processing systems to disassemble and reassemble any type of document in your organization as it moves from one machine to another. For example, your authors may create documents on PCs, but your editors may edit documents on Macintoshes, and your production staff may use Sparc stations to produce your publications. Your document structures must be thoroughly defined so that transfers between these machines lose nothing of your documents.

Once you’ve defined a document’s structure, you’ve established pigeonholes in which to place content. Once a machine knows there’s a title at the beginning of a document, it expects to see a string of characters designated as title content, and it must be at the document’s beginning. Now that the machine knows where the title is and what character string goes in that title as content, it can apply a format to that character string. But the machine must think of structure first, then the content of that document structure, and then it can think about what format that structure can appear in.

As Chapter 2, “SGML View of the World: Structure, Content, and Format,” points out, you have to re-think all documents in terms of the information building blocks they’re composed of. Your structure standards, if you have any, probably don’t do this. You might have something that tells you that all interoffice memos will have a greeting, a body, a salutation, and an electronic signature. However, the person who wrote the “standard” that contains that information probably didn’t have SGML in mind when he or she wrote it. Your standards for structure will largely be what you decide is both necessary and practical in your documents.

---

• See “Defining Structure in SGML,” p. 42

• See “What Are the Components of SGML Documents?” p. 47

• See “What Are the Components of DTDs?” p. 61

---

---

Note:  
You’ll probably have to develop your own structure standard out of a collection of sources. These structure standards will become your DTDs.

---

It will help you immensely if you use some specific forms to define your structural standards. Because they are composed of different documents and don’t look at your collection of document types the way you are looking at them now, some forms, such as the one shown in figure 6.2, can help make the difference between clarity and confusion your first time through this process.

Fig. 6.2  The form you use should identify the type of document and provide room to list all its structural parts.

The names you choose aren’t carved in stone. You’ll get a chance later to change whatever names you put on the forms. You can consider these nicknames for now.

Content Standards

Content standards usually tell you what you can say and what to cover. You might have standards that forbid you to put obscenity into your documents. This has to do with content, and content only. Perhaps you have standards that encourage you to use only black and white photography in your documents; this is also a content standard.

Particularly important are documents that tell you what to put in your documents. For example, for field repair manuals or overhaul manuals, how do you know how deep your level of breakdown should go? What document tells you when to use a warning in your manuals? How do you know what manuals to talk about software installation in? What standards describe the editorial slant in your newspaper or magazine?

What content standards determine and follow:

•  Which publications cover which subjects

•  How deeply to cover each subject in the specified publication

•  Which specific details are not appropriate for various publications

•  What components of publications should contain (for example, what tells you what a warning or a sidebar should contain)

•  Directions to exhibits of publications or examples of common practices

•  Industry standards, if any, that apply to your collection of documents

•  How graphics and non-textual information are composed

These questions get you started in the right direction. Keep your Standards and Policies sheet handy so you can write down ideas as they pop up (see fig. 6.3).

Fig. 6.3  A simple form like this that summarizes your standards and policies will help you later when you have to talk intelligently about them.

A scholastic journal might consider color graphics inappropriate for their audience while a magazine publisher might consider black and white photos undesirable. A literary magazine might publish only fiction with an occasional piece of literary criticism, while a software manual publisher might not permit actual software code to appear in his manuals. The documents that specify these types of policies are what should interest you at this point.