| Previous | Table of Contents | Next |
The more you involve your users, the more useful your SGML installation will be for them. In many corners, SGML still has an esoteric aura that scares away many users. This can be a problem when they are your employees and are getting scared away from one of the fundamental tools that they need to do their jobs. The more you encourage them to involve themselves in the overall process, the more quickly they will become accustomed to using SGML.
Moreover, your employees are in the best position to recognize what works. By involving them in creating and maintaining the SGML installation, you get their input. Even if their input is not overly technical, they can discuss nuances of documents and their structures that you could never know.
It’s worth repeating that you should use a big document sample to define your document types. As you develop your DTD, you should test as many document instances against the DTD as you have time for. This is where you can have users to help you, too. Have them bring their most obscure and difficult document instances to you. Challenge them to find the most unusual instance of the document type that you are currently working on. Mark up the document instances and parse. That will test your DTD.
You should do this frequently as you develop and add features to your DTD. It’s best to parse as you add features. That way, when you run into errors, you can track them more easily. If you parse after incorporating many changes, you won’t know which change caused the error.
• See “Parsers,” p. 242
Use several parsers in the parsing process. Use a nonvalidating parser to get the most gentle parse. When you are more confident that you have a solid structure and good content models, use a validating parser. It works your DTDs and documents more carefully and precisely. As you change and mold your DTD, make sure that you keep your original purpose for the document type in mind. Make sure that each test and its results bring you closer to the original purpose for which you defined the document type. Don’t get distracted from what you originally intended just for the sake of parsing convenience.
You should maintain three types of documentation for your DTDs:
Don’t skimp on any type of documentation. Get into the habit of maintaining documentation together with the DTDs. When you change a content model because of a parsing error on a particular document instance, put a record of that change into each type of documentation. Do this religiously. That means that you should have these documents in a particular place and in a specific format. Stick to that format. Don’t let these volumes be borrowed by people who promise to bring them back someday. Keep control over these documents so that they are not lost. At the same time, make them accessible so that they can be useful to users and updated as needed.
You should also keep a record of your decisions on document design. People often forget what they agreed upon concerning the purpose of a document design. If you keep a record of what everyone has agreed upon, you maintain control of the situation. Surprises will not occur so often.
• See “Making Comments in DTDs,” p. 214
This chapter covered DTD design issues. These are issues that affect you severely if you ignore them. The problems that these design issues cause are sometimes small, but other times they are severe. This chapter also marks the end of Part III, “Content Modeling: Developing the DTD.”
For more information, refer to the following:
| Previous | Table of Contents | Next |