| Previous | Table of Contents | Next |
As you’ve seen in previous chapters, the process of developing your own DTD can involve a number of factors. So far, you’ve looked at the SGML declaration syntax that you use to define your DTD, how to create modular DTDs, and how to make your DTD readable.
In Part II, “Document Analysis,” you examined a variety of topics relating to document analysis. These included issues relating to environment, element definition, and extending document structure. Chapters 10-12 introduced you to SGML syntax and the construction of DTDs. Now you’ll take a look at some factors relating to your DTD from a different perspective: ensuring that they fit your environment and your documents.
In this chapter, you learn how to:
When you’re done, you will have a better idea of what makes a “good” DTD, what issues should be considered when developing your own DTDs, and how DTDs can be used as a tool to gain greater consistency in your SGML documents.
After your examination of parsers is complete, you will have an understanding of what they do (and don’t do) and what you might do if you run into parsing problems.
DTD evaluation should be thought of as an iterative process. That is to say, it is a process that you’ll want to do from time to time over the course of a DTD’s lifetime. In the early phases of your SGML project, you’ll want to consider a host of issues before you even begin DTD development. Evaluating existing DTDs before you develop new ones can often be a useful exercise.
Tip:
Even if you plan to use an existing DTD (such as one that is publicly available), you should still perform DTD evaluation and analysis. Doing this will help you maintain a balance between your documents and your DTD.
While you are developing your DTD, you should continually evaluate it to make sure that what you are creating is best suited for your needs.
After you have developed your DTD and put it into production in your SGML system, you might want to re-examine it after a period of time. When you do so, you may find yourself looking at a DTD after six months, thinking “Hmmm, I think I would have done it a little differently if I were writing it today.”
This is normal. For one thing, there’s a learning curve associated with developing DTDs; you get better at it over time as you gain experience with what works and what doesn’t. Additionally, your needs, which determine how you define your document, can change over time. For example, if you create a DTD initially to handle printed documents and you later want to also support electronic delivery, you will face a number of issues in providing support to both. In other cases, there might be issues related to the particular software that you use in your SGML environment.
Writing DTDs can be thought of as a mixture of art and science. Bear in mind that there is no “perfect” DTD. Rather there are DTDs that do a very good job of modeling documents in certain situations and those that are less effective. In your examination of DTD development issues, you will take a look at some of the necessary factors to consider when developing DTDs. In this way, you’ll be able to develop the DTD that takes into consideration the environment and special needs of you and your organization.
As you examine the factors that affect what you want your DTD to do, consider the following:
As you consider how to model your documents in a DTD, there are various factors that will influence your decision. Foremost among these are issues related to the scope (or environment) of the document. Who uses it and how do they use it? What’s the place like where it’s built? How many flavors does it come in? All of these issues should play a role in how your DTD is constructed.
How Will Your Document Be Used? Consider how your document will be used. Will readers read it from front to back, or will they skip around between various chapters and sections? For example, suppose that your document is a repair manual for a car. Readers might use the manual in a variety of ways.
Some readers (such as new owners) might concentrate on introductory sections of each chapter to understand the high level topics of how their car is constructed. Others might skip around various chapters as they attempt to troubleshoot problems in their car. Still others might go step-by-step through detailed procedures to rebuild a transmission or replace valves.
As a result, certain features gain importance over others depending on the reader navigating your document. Table 13.1 illustrates how some of these features might apply to your car repair manual.
| Reader Type | Important Features |
|---|---|
| New owner | Overall features list, General tips, Descriptive introductory sections in chapters, Maintenance information, Spare parts lists |
| Troubleshooters | Diagnostic fault tables, Cross references to related sections, Detailed indexes |
| Rebuilders | Step-by-step procedures, Detailed parts lists, Assembly illustrations |
By looking at your classes of readers, you can see that different readers have different approaches to a document, resulting in a different set of important features.
| Previous | Table of Contents | Next |