| Previous | Table of Contents | Next |
In today’s world, change is everywhere. The scope of change can be dizzying. What your parents took for granted—lifetime employment with the same company, or the value of a dollar—are now subject to constant change.
In many organizations, documents are subject to change as well. Whether the cause is a company reorganization, a change in the standard document processing software, or a desire to get information on the Internet, standard documents can change over time.
If you use SGML, though, you can be protected from some of this change. For example, you are insulated from changes in document processing software. Without SGML, your collection of documents might become unusable because they rely on obsolete software.
Note:
Recall the multitude of word processors that were all the rage in the late 1970s and early 1980s. Generally consisting of a typewriter-like device, a disk drive, and maybe a video display, they stored documents in a proprietary format that could not be understood by other word processors. In those days, the common format was often the printed page.
Yet some changes will be inevitable. In fact, as you build your SGML document universe, you will probably need to make a few changes of your own. In your initial efforts in building document models, you will probably make mistakes, omissions, and faulty assumptions. The standard pieces of your modular document set will often grow as you find more shared objects.
By using modular components, you can simplify the process of making changes to your DTDs. For example, if you find that you need to add a new element to your standard chapter DTD module, you can make the change in one place—the common DTD module. Because the DTDs for each document type reference this common DTD module, you have to make only one update; all the DTDs that reference this common module require no additional changes. Had you not used a common DTD module, you might have had to make the same change across many DTDs.
• See “What Can Object-Oriented Development Techniques Do for DTD Development?” p. 535
In other words, although changes to your document structures may be inevitable, the judicious use of modular components can make those changes simpler and more manageable.
In this digital age, products often last only as long as the computers that you use. The first personal computer included a 360K floppy drive, a monochrome display, and—if you were lucky—a whopping 10M hard drive. It seems so quaint now, such a simple machine.
Although computers evolve with blinding speed, many other products do not. For example, the washing machine in your house might not be all that different from the one that many people used in the 1950s, and the lifespan of a household refrigerator runs 25 or 30 years.
It is easy to forget that products can last so long. Many of these products that last decades have documents associated with them. These documents include such things as parts lists, repair manuals, overhaul guides, and owner’s manuals.
Similarly, other documents in a company or organization have a long lifespan. Policy manuals, purchasing instructions, and employee benefit guides might evolve over the course of many years. In some cases, documentation changes only gradually in content. Other times, contents must be redone when the word processor program in use changes. Using SGML with a modular document definition can facilitate the process of maintaining documents over their lifetimes.
Note:
The longevity of your documents might be longer than you first think.
Real world DTDs are often long and complex documents that include a highly detailed model of the document architecture. Any method that simplifies DTDs and the document instances that they model can pay great dividends by making the whole process more manageable. When you use common document objects through references to shared DTD fragments, you remove the need to retype detailed document object definitions. An additional benefit is the appearance of the referencing DTD itself. Because it does not have to include all the details of common building blocks—such as paragraphs, tables, and lists—it becomes much easier to read and understand.
As you develop more DTDs, you will find more common data objects. By adding them to your reusable document modules, you can create a standard library of reusable data. Over time, this standard library can provide most of the detail that you need as you model new documents by means of DTDs. In many cases, creating new documents involves a small amount of document analysis, a quick review (and maybe revision) of the common modules, and creation of a short DTD that models the new high-level elements.
| Previous | Table of Contents | Next |