[Mirrored from: http://stdsbbs.ieee.org/aboutSPA/spasgml/sects1and2.html]

SPAsystem ® Guide for SGML Authoring Ver. 5.0.1

1. Overview

1.1 Scope

This document is a guide for working groups that are preparing IEEE standards document directly in SGML[1] using the SPAsystem SGML application.

This document assumes that the reader is, at a minimum, familiar with the basic concepts of SGML. For more information on SGML, refer to Practical SGML, by Eric van Herwijnen.[2]

1.2 Purpose

This document is intended to provide working groups with instructions for implementing the SGML application that is described in the SPAsystem authoring DTD suite.

2. Introduction

2.1 Background

SGML (Standard Generalized Markup Language, see ISO 8879 : 1986) provides a methodology for explicitly defining the structure of a class of documents. SGML can be used to define the structural elements that comprise a document; the relationships that exist between the structural elements within a document; and the attributes/values that each structural element within a document can possess. All the value-added information contained in an SGML document instance (i.e., a particular instance of a given document class, such as "letter" or "memo," etc.) relates to the structure of the document. An SGML file does not contain any information regarding the appearance (or output) of the document. Therefore, a single SGML file can be output in a variety of ways depending on the output system and media (e.g., a single file can appear in one format for on-line viewing, and in a different format when printed out).

The structure of an SGML document is defined explicitly in a document type definition (DTD). A DTD is comprised of a series of declarations that indicate the names of the tags that represent the structural elements of the document; the content model (i.e., what type of data can be contained within) of each element; and any attributes that can be associated with the elements. In this manner, the DTD forms a "blueprint" for building a structured document.

When SGML was first introduced, its use was considered primarily a "production" tool (i.e., documents were converted into SGML by the production department after the authoring process was completed). This required that every document be tagged, often by hand, prior to publication. If a document needed to be revised, it first had to be converted back into a word-processing format for the author(s) to input changes, and then the document needed to be retagged in order to be published. As a result of this cumbersome process, the production costs for most publishers increased exponentially after adopting SGML.

Some organizations attempted to defray the cost of SGML conversion by having authors create the documents in SGML. It was soon discovered that the DTDs that were created for the tagging of completed documents were impractical for use in the authoring process. Production DTDs were too large and unwieldy for authors to make sense of them. They provided authors with too many element choices and little guidance as to what elements were or how they were meant to be used. Production DTDs were also often littered with output-system-specific elements that were unnecessary and confusing to the author. It became clear that no single "kitchen sink" DTD could be used to address effectively all stages of the document life cycle. Therefore, many organizations are now adopting a "modular" approach to SGML development.

2.2 SPAsystem modular DTD approach

The purpose of the SPAsystem Authoring DTD Suite (SPA Z-30) is to create an environment that allows authors to write an IEEE standards document in SGML in a simple and intuitive manner. This is accomplished through a series of DTD modules. Each module is a small, highly structured DTD that defines a particular portion of an IEEE standards document. The modules represent the logical divisions of an IEEE standards document: clause (or section), references clause, definitions clause, bibliography, and annex. The modules allow an author to create a portion of a document (such as a single section or clause) and validate it (i.e., parse it against an SGML processing system) without the rest of the document being present. Thus, several authors can work on different parts of a document simultaneously; validate their individual parts; and then "paste" them together to create a full IEEE standards document instance.

For example, suppose a working group decides to create a standard in SGML. Writing assignments are divided among the working group. Each working group member drafts a section of the standard using the "clause" DTD. After the individual clauses have been drafted, the technical editor then pastes these clauses into a single document. Using the "references clause" DTD, the technical editor can compile a list of standards referenced in the document. Using the "definitions clause" DTD, the technical editor can compile a list of definitions for terms uniquely defined in the document. Using the "bibliography clause" DTD the technical editor can compile a list of bibliographic entries. Once all the parts of the document have been combined into a single document, the "IEEE standard" DTD can be applied to it, thereby allowing the entire document instance to be validated.

Next Section

Back to Home Page E-mail to SPA staff