Chapter 9
Extending Document Architecture

You have accomplished all the tasks related to document analysis. You now can add bells and whistles—extended features—to your documents. The bells and whistles show up as more elements. This chapter shows you how to handle nonprinting (control) information. It’s still basic SGML; it does not even push the envelope of SGML’s capabilities.

In this chapter, you learn:

•  How to add more features to a document

•  How to add revision tracking information to a document

•  How to add hypertext links to a document

•  How to add multimedia capability to a document

•  What HyTime is

•  How to upgrade an HTML Web site to an SGML Web site

Adding Features to Documents

When you add features to your documents, you add features to your document types. You must first decide which document types get which nonprinting (control) features. You take one document type at a time and decide all the features that it should have.

When you add features to a document type, you modify the document instance. You also must modify the DTD because you are dealing with all the document instances of that type. The DTD must conform to SGML and parse completely.

---

Note:  
Be careful that the features you add to one type of document apply to all the instances of that document type. In the case of the HTML DTD, that could involve all the documents on the World Wide Web.

If you modify document instances without modifying the agreed-upon DTD—in this case, HTML version 2.0—you run the risk of creating documents that cannot be viewed using standard HTML compliant browsers. This sort of problem is the seed of a current controversy on the Net: the conflict between innovation and standardization. The result is the rise of mutations of standard HTML documents that can only be viewed through proprietary browsers like Netscape.

---

---

• See “Standardization versus Innovation,” p. 315

• See “Handling Tables” and “Handling Math and Equations,” pp. 421, 424

---

Extending document architecture, therefore, involves modifying a DTD. You can add attributes to elements and add elements to the DTD. You can also add entities. This procedure might look like the following:

1.  Decide which document types get which features.

2.  Add the appropriate document structures (elements, attributes, and entities) to the first document type.

3.  Add the appropriate structures to the subsequent document types.

4.  Add the appropriate attributes to the first new element of the first document type.

5.  Add the appropriate attributes to the subsequent elements of the subsequent document types.

6.  Modify the DTDs for each document type that was modified.

7.  Parse the modified DTDs to ensure that they conform to SGML standards.

Using the HTML DTD as an example, suppose you wanted to add the ability to express complicated math equations to the HTML standard. (The proposed version 3.0 of the HTML DTD does this.) Since you have just one document type, this simplifies the process. But you first add a group of entities with which to express special math symbols. Then you must add elements that utilize these symbols in the required mathematical ways—you must add superscript and subscript elements, for example. In the case of HTML 3.0, there are structures to incorporate LaTex-like arrays for storing formatting macros to display complicated formulas. This whole architectural extension relies on a systematic modification of the DTD, as described earlier.

Figure 9.1 shows a graphical representation of how to extend document architecture.

Fig. 9.1  Extending document architecture involves adding features to the structure of a document type.

Before you add a feature to your document types, ask yourself these questions:

•  Will the feature affect other document types?

•  Will the feature change any DTDs that I do not control?

•  Will the feature require any temporary tags?

•  Does the feature require format-related extensions that I should think about?

•  Do I have input from all the people who will use the feature?

•  What notes should I make so that others can understand how all the features work together?

---

• See “The Definition Process,” p. 137

• See “Choosing Elements or Attributes,” “Dealing with Mixed-Content Models,” “Dealing with Ambiguous Content Models,” and “How Flexible Should DTDs Be?” pp. 247, 258, 259, 261

---

---

Tip:  
When you design features, always keep in mind the people who will use them. Add the new features to your element dictionary, which records and explains all the elements that you have created for your documents and DTDs. Don’t shortcut this task. The people who follow you in the project will need the information.

---

Adding Revision Tracking Information to Documents

Documents often exist at several revision levels. The revision level can be critical, especially in engineering documents. People often deal with similar documents at different revision levels, and the revision level affects how a document must be processed.

---

Note:  
Although many environments require revision tracking, engineering and manufacturing environments especially need the feature. If you expect to work on SGML documents in this type of environment, you should become an expert at adding features such as revision tracking to documents and DTDs.

Any environment where different configurations of a product or of information can possibly be confused or mixed together incorrectly should probably include revision tracking. For example, if you are building one configuration of a software or hardware product for one customer, but a slightly different configuration for a different customer, you want to ensure each customer gets the correct documentation for his or her configuration. Revision tracking helps maintain compatibility.

---