[Mirrored from: http://stdsbbs.ieee.org/aboutSPA/spasgml/sects1and2.html]
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]
This document is intended to provide working groups with instructions for implementing the SGML application that is described in the SPAsystem authoring DTD suite.
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.
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