Previous Table of Contents Next


Chapter 4
The Basic Procedure

Chapter 3 introduced you to many of the basic terms you’ll encounter again and again; this chapter shows you the overall process that makes use of those terms. By following a consistent procedure for publishing SGML documents, you can take advantage of the experience of other publishers before you. This procedure has worked for many, and it can work for you.

There are two basic categories of tasks you must complete to become an SGML publisher: design tasks and production tasks. Just as you need plans to build a skyscraper or a home, you need to design your SGML endeavor before you actually go into the production of SGML documents. Once you have the design plans, you need an orderly way of producing what you designed. The basic SGML procedure includes five tasks all together, three design tasks and two production tasks. This chapter introduces these five tasks and talks about working with consultants.

In this chapter, you learn about how to:

  Conduct document analysis
  Develop content models
  Understand output specifications
  Understand native authoring and document conversion
  Parse your documents and your DTDs
  Work with consultants

This chapter gives you the conceptual foundation for the rest of the book. For example, Part II of this book expands on the first task discussed in this chapter, document analysis. Parts III and IV deal with content modeling and markup strategies. Before you are bombarded with the details of document analysis in chapters 6 through 9, for example, you’ll need some framework to know where the process of document analysis fits.

Design tasks in this book receive more emphasis, largely because production tasks are becoming more and more automated with the introduction of “smarter” tools. Also, design tasks represent more of a mine field than production tasks because a mistake in design could cause you more problems, generally speaking, than a production problem. If you were building a house and your plans for the basement were wrong, the fact that the cement truck was an hour late would be less important. It’s more important that the house you build fits on top of the foundation than that you build the house quickly. Preparing to build an SGML publishing enterprise is much the same way—your planning needs to be right if your production is to be effective.

Document Analysis

To build an SGML publishing enterprise, you must analyze the types of documents you will publish. SGML is very concerned with document structure; it requires you to understand the structural design for each of your document types. To understand this design, you must individually look at each different type of document you deal with: memos, service bulletins, technical manuals, technical papers, parts lists, customer literature—all your document types. Document analysis is the process of understanding each different document type, such as how your memos are structurally different from your service bulletins, for example. It’s the process of understanding each type of document like a surgeon understands the human skeleton.

But just as the human skeleton is affected by the environment and other external factors over time, so SGML documents are affected by external factors. For this reason, documents must be examined first, not for their structure, but for their relationship with external policies and procedures. Only when you know what external requirements your documents must accommodate can you be certain which internal structure best suits each type of document. First you define the environment, and then you pick a document type and define it in detail. You repeat the definition process for each document type.

A surgeon must know more than the names of each part of the body; he must understand how each part relates to the rest of the body. In document analysis, you likewise must understand how each element of a document type relates to every other element in that document type; this is called defining your element relationships.

Since you’re designing the types of documents you’ll be using, you are taking a step beyond what a surgeon must know. You actually can improve upon your creation. In document analysis, this is called extending the architecture of your documents.

Whether you have a large publishing company and will deal with many document types, or whether you will publish a single type of document for the World Wide Web site, your steps in document analysis are the same. Here are the summarized steps:

1.  Define your environment.
2.  Define your elements.
3.  Relate your elements to each other.
4.  Extend your document architecture.


Previous Table of Contents Next