Part II. Document Type Design

Table of Contents

4. Document Type Needs Analysis
4.1. Preparing for the Design Work
4.1.1. Learning Basic SGML Concepts
4.1.2. Learning to Recognize Semantic Components
4.1.3. Learning the Tree Diagram Notation
4.1.4. Scoping the Work
4.1.5. Planning to Prepare Deliverables
4.1.6. Learning About Teamwork Norms
4.1.7. Gathering Analysis Input
4.2. Performing the Needs Analysis
4.2.1. Step 1: Identifying Potential Components
4.2.2. Step 2: Classifying Components
4.2.3. Step 3: Validating the Needs Against Similar Analyses
5. Document Type Modeling and Specification
5.1. Preparing for the Modeling Work
5.2. Performing the Modeling Work
5.2.1. Step 4: Selecting Semantic Components
5.2.2. Step 5: Building the Document Hierarchy
5.2.3. Step 6: Building the Information Units
5.2.4. Step 7: Building the Data-Level Elements
5.2.5. Step 8: Populating the Branches
5.2.6. Step 9: Making Connections
5.2.7. Step 10: Validating and Reviewing the Design
5.3. Producing the Document Analysis Report
5.4. Updating the Model
6. Modeling Considerations
6.1. Distinctions Between Components
6.1.1. Multiple Elements
6.1.2. Single Element in Different Contexts
6.1.3. Single Element with Partitioned Content Models
6.1.4. Single Element with Multiple Attribute Values
6.2. Container Elements Versus Flat Structures
6.3. Documents as Databases
6.4. Strictness of Models
6.5. Divisions
6.6. Paragraphs
6.7. Generated Text
6.8. Augmented Text
6.9. Graphics
7. Design Under Special Constraints
7.1. Customizing an Existing DTD
7.2. Designing Document Types as an Industry-Wide Effort

This part addresses the work that the document type design team will perform: designing the requirements for the DTD's markup model.

The complete list of steps for analysis and modeling is as follows. Steps 1 through 3 make up the analysis work, discussed in Chapter 4, Document Type Needs Analysis, and steps 4 through 10 make up the modeling work, discussed in Chapter 5, Document Type Modeling and Specification.

  1. Identify potential needs, defining them as thoroughly as possible.

  2. Classify them into logical categories, thereby taking their definition a step further.

  3. Validate the needs against other analyses of similar data.

  4. Select the needs that the markup model should ultimately address.

  5. Build the model for the document hierarchy.

  6. Build the models for the information units.

  7. Build the models for the data-level elements.

  8. Populate the remaining branches of the model.

  9. Make connections within the model and from the model to the outside world.

  10. Validate that the model is complete and that it has been informed by similar models already developed.

Chapter 6, Modeling Considerations offers advice on modeling techniques that the design team can apply, and Chapter 7, Design Under Special Constraints describes special circumstances under which the usual steps of analysis and modeling might need to change.

The analysis and modeling phases of DTD development bear some resemblance to the phases of software and systems development. The analysis work generates functional requirements, and the modeling work generates a partial design specification, which is recorded in a “document analysis report.” The DTD implementor must later design and document choices made in the final markup model and the DTD's architecture, which completes the final design specification.