Using this model, other divisions can create their own ALTERNATE content models. The designers, for example, could develop a design brief that included NOTATION elements that allowed them to include all kinds of drawings and additional information. The public relations department could do the same to include their extra logos and perhaps even create an electronic version of the company letterhead. Although the memo model won’t be able to cope with everything, XML offers it a chance to expand into new fields without becoming completely overloaded.

This is by no means the only way to accomplish this task. Instead of using an ALTERNATE element to allow expansion, it might be more useful to move the entire MAIN element definition out of the main DTD and into another file. The memo’s core functionality is primarily the header and its distribution mechanism, so this might make sense. In this case, because approximately 90% of the documents created with this DTD are simple memos, and because the newletter DTD reuses parts of the DTD under the MAIN element (e.g., PARAGRAPH), it seems simplest to keep the DTD for a simple memo in the memo DTD. Yet another option would be to move the distribution information out of the memo DTD, making it easier to reuse with other DTDs. Choosing between these options is frequently difficult and very dependent upon the particular needs of your document structures and management systems.

Even though the document management system won’t care directly about the style sheets, it can keep track of which style sheet was used where. After all, style sheets are just another link. Placing your style information into a document management tool makes it easy to foresee the impact of significant changes because the tool can warn designers which documents are about to receive the new style. Best of all, the document management system may to able to support some kind of versioning. Older documents can stay with their older style sheet, whereas newer documents receive a facelift. The capabilities of the management system, of course, may vary.

It’s probably best to create a separate style sheet for each DTD, even if you combine DTDs on a regular basis. In that way, the user’s machine doesn’t waste cycles parsing style information it won’t be using, and developers don’t waste time searching through an enormous collection of styles. Choose a naming convention and stick with it. I tend to name my DTD files name.dtd and the corresponding CSS files name.css. You can keep them in separate directories if you like but try to maintain as much parallelism as possible between the two structures so parts don’t disappear. When it’s time to modify a DTD, create a new DTD file (and associated CSS or other style sheet file) so that older documents don’t suddenly become invalid. Document management systems require humans to behave systematically—changing a DTD significantly could leave the document system stranded with files of documents it can’t parse. Although writing conversion programs is possible, it is rarely fun, and changing a significant library of documents by hand is even more tedious.

Building Histories: A DTD for Corporate Memory

History is rarely a favorite corporate subject. The future is always in sharp focus: companies strive to make the next quarter, the next year, or even the next decade their best one yet. Yesterday’s sales figures may have paid for a new car or cost a promised bonus, but today’s holdings and tomorrow’s profits are of greater concern. As a result, companies often let their history slide. Memos and reports may accumulate in file cabinets, but periodically they get emptied or shipped to far-off storage, and key employees leave the company or retire. As employees have become more mobile, the odds of losing the person “who knows where all the bodies are buried” greatly increase. Most companies lack strategies for debriefing employees and organizing the information, costing wasted hours spent trying to determine what happened when a legal battle or a customer inquiry requires a reexamination of past activity.

The document structures we’ll build in this example are designed expressly to keep some of that history alive and available at the end of a project or when an employee changes positions. Combined with a document management system, the information stored in that structure will make producing quick, comprehensive answers to questions about past projects easier. Large corporations that write proposals for large projects are often required to present past performance references; the information contained in this system will make it far easier for companies to describe their previous work, saving expensive resources for use on developing the forward-looking parts of the proposal.

This project and its associated DTDs could grow to be gigantic, especially if it expanded from project history into project management. This discussion will explore only some of the basic needs of the project and develop some of the core document types.

This project needs a considerable amount of political work before DTD design can even begin. Structured documents are useless if they aren’t applied consistently. Even though it’s easy to require that a particular element appear in a document, it’s difficult to require that individuals who are already on their way out the door fill out a few acres of paperwork. Building this document database successfully requires adding it to the process as a standard business procedure. The needs of that process will probably have direct effects on the nature of the DTD and the level of flexibility required. If this system is likely to be used on a regular basis, it might even be worthwhile to build a custom interview application to collect the information.