Extending Document Architecture

You extend a document’s architecture when you add features to its design. Suppose you want to show equations in your magazine article documents. How do you get superscripts and subscripts? How would you get all the special symbols so commonly used in mathematics? You have to add them to your document design. That’s an example of extending document architecture.

Sometimes in the middle or even after the design process is completed, you’ll find capabilities you need to add. Fortunately, SGML allows you to do this. To make these changes easier to add in the future, you should count on allowing room to grow while you extend your document architecture. Just because you extend the architecture of documents by adding elements and attributes does not mean you have to use all those structures right away. You could even add elements like <future1> and <future2> that you’ll rename at some point in the future when their use becomes expedient. Figure 4.3 shows an example of how you might add functionality to a memo document type.

Fig. 4.3  Extending a document’s architecture means adding functionality to it.

---

Note:  
The word “feature” has special meaning in SGML. The ISO 8879 standard specifies many different features that legally may be used within an SGML application. These features are commonly specified in the SGML Declaration and would explain whether, for example, features like short references are used and templates are permissible. I’m using “feature” here in the more familiar sense of the word rather than in the SGML sense of the word.

---

Developing the DTD (Content Modeling)

The second task of the design phase is to develop the DTD. This is where you state the results of your document analysis according to SGML syntax. Up until now, you’ve been doing the real work (believe it or not!). Once you understand SGML syntax, developing your DTD is primarily just a necessary detail. Completing your document analysis requires far more scrutiny than developing the DTD. Now you just have to express your document analysis in SGML form.

Developing the DTD involves four basic tasks:

•  Make your SGML DTD declarations

•  Express all your content models and element groups (DTD components) and their relationships

•  Parse your DTDs

•  Follow good SGML design practice

As usual, the scope of your SGML endeavor determines the length of this overall process. This step can be either very extensive or completed in an afternoon. Two different operations can look very different in terms of the complexity of their DTD development process. Part III of this book is devoted to developing the DTD for both large and small installations.

---

• See “Creating an SGML Environment from Scratch,” and “Converting Existing Documents into SGML (Filtering),” pp. 88, 96

---

---

Note:  
Large SGML publishers differ from small publishers, not only in their document complexity but in the amount of historical or legacy data they must convert into SGML documents. Conversion of existing documents can be a major undertaking and can require extra DTD development above and beyond what is required for SGML authoring.

---

Making Your DTD Declarations

After you’ve decided what elements go into your DTD, you need to formally declare your document structures.

There are five structures you have to know how to declare:

•  Document types

•  Elements

•  Attributes

•  Entities

•  Comments

When you’ve learned how to declare these document structures, you’re well on your way to knowing SGML. The purpose of having an international standard like SGML is to specify a common universal way of expressing document structures so that any machine anywhere can recognize and reconstruct any type of document. In order for a machine to recognize something so abstract as a document structure—say, a quotation or a title—there must be highly standardized ways of identifying these structures. When you make the five declarations identified above in your DTD, you’re giving the machine, as well as any human operator, a blueprint by which to assemble and dis-assemble any document instance of the type defined in that DTD.

---

Tip:  
It’s best to start the DTD simply, with just a few elements, and then parse it. That way you can make sure it’s working with just a few elements. Then add more elements and parse it again. Do this, and you’ll identify problem areas easily and save time. You won’t spend hours trying to find the bad declaration. Also, you’ll get extra practice parsing!

---