CHAPTER 7.1

Chapter 7: Applying Standards

"If you cannot convince them, confuse them." -Harry S. Truman
Standards can be used in many ways. Properly used document standards can improve quality and increase productivity. Most important, the proper use of standards will let you keep and reuse your investment in the document's content.
Standards are also an enabling technology. Both document interchange and electronic distribution depend on standards. In this chapter, we examine the use of document and electronic distribution standards.
Before we examine several of the ways in which standards can be used, let's step back from the trees and look at the forest again. What do standards provide and why bother at all?

A single standard cannot possibly satisfy all requirements all the time. To believe that any one standard is a magic bullet is foolish, although technological developments often breed technology bigots. One particular new solution does not automatically negate others. Most standards have some value under certain circumstances. A few are extremely valuable under many circumstances. Value, however, often comes with a price tagcomplexity.
For any particular project, you may be the only one who understands the particular requirements. You may be the only one aware of the future uses or potential future uses of the documents. The potential for producing multiple products and using the document's raw content in multiple ways is a powerful reason to pay attention to standards. For example, one vendor can take an SGML document database and turn it into an on-line hypertext document.(1) Of course, some people suggest that you really need a compelling reason not to use HTML. If your project has archival requirements, standards are your best bet for maintaining the integrity of your archive. If none of these concerns is realistic, you may indeed be better off using systems that let you easily accomplish the project, rather than paying too much attention to standards.
Document standards are complex and address many types of document requirements. As is true of any complex technology, document standards can be misused. Usually, the fundamental assumptions of the standard form conceptual boundaries that are very difficult to cross. A good example of these boundaries are the various efforts over the years to provide style capabilities to SGML. SGML does not inherently take into account the visual appearance of a document. To provide such a capability, other standards are being developed with a great deal of effort and complexity.(2)
7 . 1 Choosing Standards

The first action you must take is to pick a standard. The selection process can become very complex. What is the budget? How long do you have to complete the project? Are new software and/or hardware systems required? Does the staff have sufficient expertise? Will the document be edited by another organization? You should ask these types of questions when deciding among the various document processing standards and systems.
An amazingly large number of complex standards are available. They have complex relationships with each other. A number of significant activities have evolved to pick and choose a set of standards that work together. The methods used by these activities can prove useful for any organization. The following list contains a few suggested questions to ask in the process of picking a document standard and document processing systems for a project.
QUESTIONS FOR STANDARDS SELECTION

Is there a longterm archival requirement?
Some industries have legal requirements that mandate that information must be available for 20 years or more. Airplane manufacturers are one example. In that period of time, all aspects of the computer systems will have changed, such as the hardware, operating system, and retrieval and display programs.
Is there a financial or other need to produce multiple products from the same content?
High up-front investment in content can be spread among several products if there is a mechanism (that is, the proper use of standards) for reusing the content.
What are the document exchange requirements?
Will the document be used by other departments or organizations for further editing or printing? In either case, you must check that the receiving system has the proper environment: the correct collection of software; fonts; and the ability to edit, view, or print any graphics included in the document.
Is there a need to localize (internationalize) the document?
If the document and/or the document processing system must be used in international markets on systems with other character sets, you must check that localized versions of the document processing system exist. In addition, there may be other foreign requirements, either corporate or government, that mandate the use of particular standards.
Is the staff knowledgeable about a particular document processing system?
Ordering a switch from one document processing system to another may be more harmful than helpful. The expense in staff retraining can be significant. One alternative to a forced switch is to investigate document conversion systems or services. Of course, it may be wise to bite the bullet and adapt to newer or better technology.
Let's examine in more detail some aspects of the selection process and the use of standards once selected.
7 . 1 . 1 The Corporate Publishing Standard

"We should distrust any enterprise that requires new clothes." -Henry David Thoreau
Many organizations have their own corporate style and publishing guidelines. Two areas that are often standardized are the document style and the document processing system. Within any organization with substantial publishing requirements, it is important to look at the requirements for exchange, style, and systems. Document exchange is easy to overlook and is the source of many problems.
Perhaps the best example of a corporate publishing standard is the XEROX Publishing Standard: A Manual of Style and Design.(3) This book encompasses the entire range of printed material for the corporation. More than a specification of document types, it discusses the process of publishing, the structure of documents, writing style, and visual design. While it is an amazingly complete reference for the publishing process and standardized document style, it does not address any document exchange or processing issues.
Many organizations simply pick one system, such as WordPerfect, and declare it as the corporate standard. In some respects, this is a perfectly reasonable approach. It ensures that people can pass documents among one another reliably. It also has the significant downside of tying the organization to a particular software vendor and a particular hardware platform. In addition, your organization may have problems teaming with other organizations that use a different internal standard. It's almost always possible to come up with an ad hoc interchange solution, but eventually the effort required to maintain such a process will be greater than the benefit. Therefore, a careful analysis of document exchange and processing needs should pay off in the long term.
It is important to create an organizational style that is easy and convenient to use by the staff. One straightforward approach of ensuring this is to create an organizational style with a particular document processing system in mind. Doing so should not significantly constrain the document styles you desire, because even the simpler word processor systems have the ability to define sequences of actions (macros) and visual elements (styles). MS Word even has a built in language, called WordBasic, to define complex macros.
Organizationspecific styles and commands are useful tools to ensure document consistency throughout an organization. However, be aware that simply specifying a collection of styles and commands is insufficient. A document that lists recommended practices or provides a style guide must also be created and distributed to the staff so that everyone knows how to use the styles and commands.
The corporate style used by an organization can also get into the specifics of font selection. Apple Computer uses particular fonts in all its manuals and even prints the following identification inside the back covers of its manuals: "Text type and display type are Apple's corporate font, a condensed version of Garamond. Bullets are ITC Zapf Dingbats\xa8 . Some elements, such as program listings, are set in Apple Courier, a fixed-width font."
The specific font choices are not important, but consistency is extremely important. The consistent usage of fonts, headers and footers, document structuring conventions, and layouts will give your organization a more professional look. Readers will also get used to particular visual cues and become tuned to the document elements of interest.
Individual organizations select collections of standards and have the freedom to specify any type of software and hardware to implement and support those standards. Governments often cannot specify a particular vendor's product but must rely on a functional specification. The goal of vendor independence is also valuable for private business.
Any organization is wise not to use a sole source to address a particular problem. This is a well known principle of manufacturing; the manufacturer almost always will seek out multiple sources of components before starting production. This principle is much the same for software. Standards Profiles are one methodology used by the U.S. Government. They present guidelines for the selection of collections of standards that work together, allowing the government to choose from multiple sources of software components that conform to the standards.
7 . 1 . 2 Standards Profiles

In a literal sense, the phrase "using standards" is the subject of profiles. A profile is a collection of a particular set of specifications or standards to accomplish some function. The profile may also add restrictions to the exact usage of a standard. For example, military standards (MIL-STDS) can mandate the use of existing national or international standards with additional restrictions or functionality.(4) The Application Portability Profile (APP) is one methodology that is being used by the U.S. Government in the domain of open systems as a framework for systems integration.
From the Executive Summary of Application Portability Profile (APP) The U.S. Government's Open System Environment Profile Version 3.0(5):
An Open System Environment (OSE) encompasses the functionality needed to provide interoperability, portability, and scalability of computerized applications distributed across networks of heterogeneous, multivendor hardware/software/communications platforms. The OSE forms an extensible framework that allows services, interfaces, protocols, and supporting data formats to be defined in terms of nonproprietary specifications that evolve through open (public), consensus-based forums.
A selected suite of specifications that define the interfaces, services, protocols, and data formats for a particular class or domain of applications is called a profile. The Application Portability Profile (APP) integrates industry, Federal, national, international, and other specifications into a Federal application profile to provide functionality necessary to accommodate a broad range of Federal information technology requirements.

The APP refers both to ODA and SGML as possible document interchange standards. There is no attempt to reconcile differences in functionality; however, both sit in the architectural "slot" of data interchange services.
The entire methodology of profiles makes an amazing amount of sense. The term profiles in this context comes from the formal standards domain. From The Open Book by Marshall Rose comes the following explanation:(6)
A standard often contains many more options than can be implemented altogether. If each vendor implements only a subset of options, there is no guarantee that any two vendors will implement the same subset. The result is systems that are interoperable in theory, but not in practice!
An important pragmatic step is to identify a common subset of options and related practices that can be used effectively. This is the purpose of groups that promulgate functional profiles.
Standards are often meant to operate in areas of very different scope. Profiles provide a framework within which the standards function.
For example, a document archive system may need to function at many different levels. At the system level, there is the operating system; at the database level, there is the query language; at the document level, there are textretrieval issues; at the document content level, there is structure. In addition, for viewing or printing purposes, there are font issues, and for document interchange purposes, all the above affect the system. Standards exist for each of these domains, and profiles provide guidance for their use.
7 . 1 . 3 CALS and Electronic Publishing

CALS, the Computer-aided Acquisition and Logistic Support project within the Office of the Secretary of Defense (OSD) of the U.S. Government, has had a significant impact on the electronic publishing industry. One key goal of the CALS project is to reduce the use of paper, and this goal has been embraced by virtually all participants.
We're not talking about eliminating a few notebooks, either. Any significant project run by the Department of Defense (DoD) requires warehouses of documents. Extensive documentation is not a fabrication of DoD; instead, it results from the extremely large, complex, interrelated contracts with literally thousands of contractors and subcontractors involved in a single project. Managing such complexity requires careful attention to standards. The careful use of standards is a key element in the quest to reduce the cost of these projects.
SGML is one of the CALSselected standards for document processing. Likewise, the rapid adoption of SGML by document processing vendors was significantly influenced by the notion of potential CALS customers. There exist several specific CALS document type definitions (DTDs) that define the structure of a CALScompliant document. Once a body of text has been properly tagged, it can be used in a number of ways. (For a more through discussion on the variety of uses, see Section 7 . 3 Multiple Use in this chapter.)
In addition to the work on document processing for printed documents, the CALS(7) arena is experiencing a great deal of interest in creating on-line, interactive documents. This effort is called the Interactive Electronic Technical Manual (IETM). Its concept is to allow engineers with portable computers equipped with CD-ROM drives to interactively browse through maintenance manuals, at the site of a repair (for example, in an aircraft hanger) or in the field.

Example IETM application(8)

This work will probably use and spur more implementations of HyTime, a hypermedia standard based on SGML. (See Section 5 . 3 . 4 HyTime in Chapter 5 Document Standards.) Given the complexity of requirements in the military, a set of classes or functional levels of IETM manuals has been defined by the Naval Surface Warfare Command Carderock Division (NSWCCD). The classes are "fairly broad," and "The class definitions, however are insufficient for use on contracts." However, they are illustrative of a coherent approach to the creation of complex document requirements.
Following are the IETM class definitions:

Class 1
Electronically Indexed Pages

Display

. Full page viewing
. Page-turner/Next function
. Intelligent index for user access to page images
. Page integrity preserved

Data Format

. BitMap (raster)
. Indexing and header files (Navy Mil 29532)
. MIL-R-28001 or Postscript pages
. Generic COTS imaging system formats

Funtionality

. Access pages by intelligent index/header info
. View page with pan, zoom, etc., tools
. Limited use of hot-spots
. Useful for library or reference use

Class 2
Electronically Scrolling Documents

Display

. Primary view is scrolling text window
. Hot-spot access (Hyper-links) to other text or graphics
. User selection and navigation aids (key-word search, on-line indices
. Minimal text-formatting for display
. User selectable call to (launch) another process

Data Format

. Text - ASCII
. Graphics -whatever viewer support (e.g., BMP or CALS)
. Can be SGML tagged - no page breaks (browser)
. Access/index often COTS dependent with Hypertext browser
. Generic: COTS with Hypertext browser

Funtionality

. Browse through scrolling info
. User selection of graphics or hot-spot reference to more text
. Hot-spot and cross-reference usually added after original authoring

Class 3
Linearly Structured IETMS

Display

. View smaller logical block of textless use of scrolling
. Interaction through dialog boxes
. Interaction per MIL-M-87268 to extent possible
. Text and graphic simultaneously displayed in separate window when keyed together EXAMPLE

Data Format

. Linear ASCII with SGML tags
. SGML with content vice format tags
. Maximum use of MIL-D-87269
. Generic: SGML tags equivalent to MIL-D-87269

Funtionality

. Dialog-driven interaction
. Logical display of data in accordance with content
. Logical NEXT and BACK functions
. User-selectable cross-refs and indices
. Content-specific help available

Class 4
Hierarchically Structured IETMs

Display

. View smaller logical block of textvery limited use of scrolling
. Interaction through dialog boxes with user prompts
. Interaction per MIL-M-87268
. Text and graphic simultaneously displayed in separate window whenkeyed together EXAMPLE

Data Format

. Fully attributed DB elements (MIL-D-87269)
. MIL-D-87269 content tags with full conformance with Generic Level
. Object Outlines (architectural forms)
. Authored directly to database for interactive electronic output
. Data managed by a DBMS
. Interactive features "authored in" voice added-on
. Generic: COTS equal to MIL-D-87269 data definition and tags

Funtionality

. Dialog-driven interaction
. Logical display of data in accordance with content
. Logical NEXT and BACK functions
. Useful as interactive maintenance aid
. User-selectable cross-refs and indices
. Content specific help available

Class 5
Integrated Data Base (IETIS)

Display

. Same as Class 4 for IETM function
. Interactive electronic display per MIL-M-87268
. Expert system allows same display session and view system to providesimultaneous access to many differing functions (e.g., supply, training,troubleshooting)

Data Format

. IETM info integrated at the datalevel with other application info
. Does not use separate databases for other application data.
. Identical to Class 4 standards for IETM applications data per
. MIL-D-87269
. Coding for Expert Systems and AI modules when used
. Generic: COTS equal to MIL-D-87269 data definition and tags

Funtionality

. Single viewing system for simultaneous access to multiple info sources
. Same as Class 4 for IETM functions
. Expert system to assist in NEXT functions, based on info gathered in session

One prime motivation behind the selection and development of a series of standards is the desire for meaningful exchange of documents. Contractors and subcontractors would certainly work together more efficiently if they could exchange documents electronically. Document exchange is a deceptively complex problem, as we will show in the next section.

[SECTION 7.2] [TABLE OF CONTENTS]

Skip to chapter[1][2][3][4][5][6][7][8][9]

Legal Statement