Purpose

Document Type Definition (DTD)

SGML markup

Output Specification (OS)

Electronic Review

Partial Documents

NATO CALS SGML Registry / NATOCALS SGML Library

Software Tools

Purpose

SGML establishes requirements for the digital interchange of technical publication text. Data prepared in conformance to SGML will facilitate the automated storage, retrieval, interchange, and processing of technical documents from heterogeneous data sources.

Document Type Definition (DTD)

The CALS SGML standard defines both a methodology and a high level computer language for document representation. It provides a coherent and unambiguous grammar and syntax for describing whatever a user chooses to identify within a document regardless of the type of document or the nature of the document's text and provides a formal markup procedure, also independent of system and output environments for this purpose. The definition of the document's structure or content in terms of "elements", their "attributes", "entities", and other components is a called "Document Type Definition (DTD)". A DTD defines the structure or content of a specific class of documents.

SGML markup

"SGML markup" (or an "SGML document instance") consists of unformatted text with inserted SGML "tags" which correspond to the elements and attributes of the DTD. These tags identify elements of the text (e.g., titles, paragraphs, tables, footnotes) defined in the document's DTD. The "marked up" document (or SGML document instance) can then be "parsed" using special software to determine if the document's tagging conforms to the DTD.

In order to format an SGML source file, associated formatting information must be provided. This associated formatting information must define formatting characteristics such as a page model, font and family characteristics, point size, indenting, etc. In addition, these formatting characteristics must be responsive to certain SGML tags. For example, a "paragraph" tag may trigger a change in the line leading or a "chapter title" tag may trigger "bolding" and "center" functions. The associated formatting information are provided in the form of an "Output Specification" (OS) DTD.

Output Specification (OS)

The OS DTD defines a finite set of formatting characteristics used to rigorously describe the composition processing functions to be performed with respect to the tags of a SGML source file. A Formatting Output Specification Instance (FOSI) is an instance of the OS DTD. The FOSI defines values for the formatting characteristics defined in the OS DTD for every SGML element used in the document DTD, taking into account every context in which the SGML element has a unique formatting requirement. In example, a title of a TM chapter is formatted differently than a title of a TM subparagraph. The objective of the FOSI is to rigorously define the format style of the document to be produced from the SGML tagged source file, as required by the appropriate functional specification.

A FOSI should be developed for each DTD to describe all default formatting characteristics necessary to compose and publish a document authored according to that DTD. The FOSI should be delivered with the SGML source tagged file. Since all FOSIs will be written with respect to the standard OS (paper medium), vendors will be able to develop software that can accept and process FOSIs and interface with the publishing software.

Electronic Review

MIL-M-28001B provides a mechanism which enables an electronic review and comment capability for SGML tagged source files. This capability allows reviewers located in diverse environments to make and exchange comments electronically on multiple copies of a document file over a network. The comments may then be sorted, processed, and incorporated into the document by the file "owner". The mechanism for electronic review of SGML tagged source files consists of certain SGML constructs which are incorporated into a DTD for a given document type. These SGML constructs have been defined as generally as possible to take into account the many kinds of reviews: internal contractor reviews, Government reviews, contractor/Government reviews, specification reviews, etc.

Plans for future extensions of electronic review include both a CALS graphics comment capability using SGML tagged for the comments, and a capability to link SGML text and CALS graphics files for related changes. Efforts will also be made to develop a more precise addressing mechanism for indicating the location within document elements of a proposed change.

Partial Documents

Partial document delivery is used to transmit source SGML tagged source data either as an interim deliverable or as an update package containing data for a document that has been previously delivered. Its purpose is to minimize the retransmission of unchanged data or to indicate incomplete data. Partial document delivery is not intended to address the issues of page integrity or fidelity, nor is it intended to include specific change pages. The intent of this methodology is to allow the delivery of certain portions of a source document such that the receiving system can identify the location of the information in the original document and perform the appropriate addition, deletion, or replacement operations. Both the manner in which this is accomplished and the effect of the change on composition depends on the receiving system.

NATO CALS SGML Registry / NATOCALS SGML Library

The NATO CALS Organisation is investigating the requirements for the development and maintenance of a NATO CALS SGML Library (NCSL).

It is envisioned that a NATO CALS SGML Registrar will administer the NATO CALS SGML Registry (NCSR), a central registry office where DTDs and FOSIs will be registered. The NCSR will maintain a NATO CALS SGML Library which will be an on-line database containing all SGML elements and attributes that have been defined, with cross references to DTDs and governing military specifications. The NATO CALS SGML Registry will require adherence to basic guidelines for acceptance of SGML tags/attributes. Some of these guidelines are:

Querying the NCSL for a suitable registered DTD in lieu of developing a new DTD If a new DTD is to be developed, compare tag requirements with the tags currently registered in the NCSL. Utilize "generic" elements as much as possible. For example, the requirement for a "group assembly parts list" can utilize an existing NCSL element "pl" (parts list). Accordingly, the NCSL should not contain "redundant" elements, i.e., different tags for the same information.
• If no existing NCSL element is deemed suitable, develop a new element and submit it to the NCSR for inclusion into the NCSL. The NCSR will require that the element be unique (i.e., no existing NCSL element will suffice); that (if possible), a generic tag name be used to facilitate NATO-wide use; and that the tag name satisfy naming conventions defined by the NCSR.

Software Tools

Currently, there are no tests for vendor products claiming conformance to MIL-M-28001. Such MIL-M-28001 product conformance testing will depend upon the product's function. For instance, conformance testing of SGML parsers entails the correct interpretation of ISO 8879. Conformance testing of "auto -taggers" or "authoring stations" would be limited to determining the parsability of the instances generated, and again would involve correct ISO 8879 interpretation. With few exceptions, there is no disagreement regarding the correct interpretation of ISO 8879.

The vendor community is aware of the evolving nature of MIL-M-28001. Some vendors are waiting until the standard is finalized, while other vendors are undertaking full implementations at the present time. A large vendor community is represented on the Electronic Publishing Committee. For the CALS environment, vendors supporting MIL-M-28001 should not "hard-code" their systems to process only a single DTD or FOSI. Certainly, most users will be processing a variety of technical publications which must conform to multiple DTDs and will require a system that can be configured to adapt to new and changing requirements as they arise.

Currently there are various types of SGML software products on the market. These include:

• SGML parsers. Such parsers check DTDs for conformance to the SGML grammar and syntax. They also check document instances for conformance to a given DTD. They return error reports on errors found in the parsing process. Many other SGML software packages (e.g., SGML editors) come with a "built-in" parser.
• SGML authoring and editing software which "understands" the DTD as it is given. Such software guides an author through the creation of a document, not requiring the author to type in the SGML tags. The keyed-in text is automatically formatted and displayed (non-WYSIWYG) on the screen.
• SGML Publishing systems which accept an SGML-tagged document and associated graphics and compose the entire document in accordance with the document's format specifications, whether in the form of a FOSI, or system-internal "style-sheet".
• Software which automatically tags an ASCII file based on format -driven triggers. Most of the "structure" type tags (for paragraphs, lists, etc.) can be automatically generated without any trouble. However, unless the software is very sophisticated, the "content" type tags (for cross references, equipment numbers, etc.) cannot be automatically generated. Content type tags are very important in data base applications. This "auto-tagging" software can be used in conjunction with media converters to translate formatted "system -dependent" files (i.e., "WordPerfect") into SGML files.