TABLE OF CONTENTS

   

LIST OF FIGURES

      

Figure 2.6.2-1  IETM Functional Architecture
Figure 4.2.3-1  Principle Components of the CALS Vision and Strategy

LIST OF TABLES

      

      

Military Specifications and Standards:  Performance specifications shall be used when purchasing new systems, major modifications, upgrades to current systems, and non-developmental and commercial items for programs in any acquisition category. If it is not practicable to use a performance specification, a non­Governmental standard shall be used. Since there will be cases when military specifications are needed to define an exact design solution because there is no acceptable non­Governmental standard or because the use of a performance specification or non­Governmental standard is not cost effective, the use of military specifications and standards is authorized as a last resort, with an appropriate waiver.

The key phrase here is "the use of military specifications and standards is authorized as a last resort, with an appropriate waiver."

To assess different migration alternatives, this report considers significant issues associated with the current state of the DoD IETM specifications (Section 2.0). In Section 3.0, a Standard/Specification Evaluation Methodology (SEM) is provided that was designed for assisting in the comparative analysis of the DoD IETM specifications with existing non-defense standards. Following this, in Section 4.0 various defense and non­defense alternatives and issues are addressed and identified. The non-defense options are categorized into three main alternatives:

1. Direct standardization,
2. Existing non-defense standards, and
3. Standardization through the Standard for the Exchange of Product model data (STEP) initiative.

Direct standardization addresses transformation of the DoD IETM specifications to an International Organization for Standardization (ISO) or American National Standards Institute (ANSI) standard by describing the standardization processes required by each. In Section 4.2.2, the direct use of an existing non-defense standard and the incorporation of requirements from the DoD IETM specifications within various existing Technical Manual (TM) related non­defense specifications/standards is addressed. Three existing non­defense standards are analyzed.

• AECMA 1000D:  The Association Europeanne Des Constructeurs De Material Aerospatiale (AECMA) (also referred to in English as the European Association of Aerospace Industries) Specification 1000D, International Specification for Technical Publications Utilizing a Common Source Database,
• ATA 2100:  Air Transport Association of America (ATA) Specification 2100, Digital Data Standards for Aircraft Support, and
• J2008:  Society of Automotive Engineers (SAE) Draft Technical Report, Recommended Organization of Vehicle Service Information.

Standardization Through STEP, Section 4.2.3, discusses the standardization of IETMs through the development of an appropriate Application Protocol (AP) and relevant work being done within the STEP community.

Following the sections on migration alternatives, Section 5.0 discusses the use of and compliance to the IETM specifications within DoD. Finally, Section 6.0 provides recommendations concerning defense and non-defense IETM standardization solutions for both the short term and the long term.

      

1. The Content Data Model (CDM) methodology in MIL­D­87269,
2. The requirements in MIL­M­87268,
3. The missing view package specification,
4. Legacy data and the IETM specifications, and
5. IETM/training integration.

Following these, additional perspectives and issues that have arisen in a new CALS Industry Steering Group (ISG) Standards Division special projects committee (the Special Project ­ Hypermedia Information Systems (SP­HIS) Committee) are presented. The perspectives and issues that are given are highly relevant to both defense and non­defense IETM standardization considerations. Note that not all issues associated with the IETM specifications are provided here in Section 2.0. Others, including the controversial issue of MIL­D­87269 versus the MIL­PRF­28001 Presentation Specification (PS) methodology, are discussed in later sections.

2.1  The CDM Methodology

3.1.4  Additional content specific Document Type Definitions (DTD):  When specified, additional content specific DTDs shall be used in addition to or instead of the content specific DTD defined in Appendices B and D of this specification (see 6.2). These DTDs shall be incorporated into the overall CDM in accordance with the requirements of 3.2.

3.2  Generic layer:  The generic layer of the CDM is defined in the DTD listed in Appendix A. This DTD provides templates, which shall be used to define content specific elements. The generic layer includes a definition for each template and the attribute lists associated with the template. The DTD provides a definition of three other data types: primitive data elements that shall remain standard across all content specific applications; user interaction elements, called dialogs; and the context filtering elements, which shall be used to provide the most appropriate information to a user.

Requirement 3.2 states that the templates given in the generic layer DTD shall be used to define content-specific elements (and therefore governs the development of any content-specific layer DTD). These templates are classified as Node, Node Alternatives, Node Sequence, If Node, and Loop Node. Each template has two components:  (1) a set of semantic rules that govern the template's activities and (2) a list of attributes. In addition, the generic layer DTD contains primitive data elements, user interaction elements, and context filtering elements that are supposed to remain standard across all developed content-specific layer DTDs.

The rationale behind these requirements is to enable arbitrary processing engines (e.g., for DataBase (DB) population, presentation systems, etc.) to correctly interpret SGML­encoded IETM data. This capability is facilitated by the generic layer DTD. The generic layer DTD can be described as a meta-DTD. Note that in the SGML/Hypermedia, Time-Based Structuring Language (HyTime) community the generic layer DTD is not considered a meta-DTD in the strict sense. In the strict sense, a meta-DTD following meta­DTD formalism is not itself a DTD that contains defined elements and attributes. The meta­DTD instead gives rigorous formal guidance for the creation of conforming DTDs [4]. This issue, however, is insignificant and does not adversely affect system design or implementation.

The meta­DTD approach taken within MIL­D­87269 is a very appropriate approach for IETMs [5]. This approach enables the development of DTDs that contain arbitrary content-intensive static and dynamic elements. In theory, then, as long as the elements conform to the generic layer templates (and use the generic layer elements/attributes), arbitrary compliant IETM processing engines will be capable of intelligently interpreting the encoded data. In terms of presentation-related portability and interoperabililty, this meta­DTD approach would not be so critical if there was a widely accepted "stylesheet" standard that included dynamic processing instructions for dynamic data elements and data element constructs. Because such a "stylesheet" standard is not yet available, the meta­DTD approach is the best way to go.

Although the meta­DTD approach is most appropriate for IETM standardization, there are problems.

• Independent IETM system implementations that use even the same content-specific layer DTD generally cannot process each other's data.
• Important elements (e.g., graphics) and attributes are not specified in sufficient detail to guarantee consistent interpretation of generic layer elements.
• Processing of arbitrary content-specific layers has not become a high-priority for developers.
• There is a lack of products from the vendor community.

The fact that different IETM system implementations using the same content-specific layer DTD generally cannot process others' data is primarily due to the second item. IETM system implementations are generally custom designed systems that may or may not include customized Commercial Off-the-Shelf (COTS) software. Although the processing of arbitrary content-specific layers has not "caught on" there is at least one notable attempt by Aquidneck Management Associates (AMA) and Softquad (the IETM Viewer). This IETM Viewer is being designed specifically to handle arbitrary content-specific layers developed in accordance with MIL­D­87269. It is not clear, however, when this development will be completed.

The primary issue here is the future of the CDM concept. When migrating MIL­D­87269 to a non-defense standard or specification, should this concept and its associated requirements be retained? If the CDM concept is retained, should the ambiguities associated with the generic layer be cleared up? The real question is, given the issues above, what is the Government gaining by maintaining these requirements in their current form? If independent implementations cannot directly exchange data through this meta-DTD approach, then it seems that little or nothing is being gained and a less complex and expensive alternative should be developed.

2.2  MIL-M-87268

Although not all opinions fit precisely into these categories, the two predominant schools of thought are basically those that say the requirements in MIL­M­87268 are absolutely necessary for DoD and those that say the requirements in MIL­M­87268 are absolutely unnecessary.

Among those that regard MIL­M­87268 as necessary, it has been stated that this specification is all that is necessary for developing IETMs. It seems that the IETM, from their perspective, is regarded as simply a document (similar to the traditional paper manuals) and all that matters is that the "document" is in a consistent and recognizable structure (in terms of presentation). The nature of the data that constitute the IETM, and the degree that it is in some standardized format seems unimportant to them (some say that MIL­D­87269 should be abandoned altogether). Their opinions regarding MIL­M­87268 seem reasonable when looked at from the perspective of a maintenance technician. These same opinions and their rationale, on the other hand, seem unreasonable when looked at from a larger organizational perspective where many IETMs must be acquired, exchanged, presented, and maintained.

Conversely, some who regard MIL­M­87268 as unnecessary have stated that the nature of the underlying data is all that matters. This is stated with the reasoning that attempts to maintain some semblance of a common user interface are not necessary and are, in fact, too much of a burden (given that IETMs are developed by multiple contractors/subcontractors, where synchronization of presentable IETM components may be required). Those who maintain this opinion further rationalize it by stating that technicians never work on a system that they have not been trained on; therefore, a common user interface, and in fact MIL­M­87268 itself, is not needed.

The real issue here is the future of MIL­M­87268. Although there are some opinions to the contrary, and some requirements should be modified or altogether deleted, it seems that there is a need for some standard or specification regarding presentation of IETM data. The issue then is what changes to make.

2.3  View Package Specification

The top candidate for becoming an "official" view package specification for DoD IETMs is the U.S. Navy's Metafile for Interactive Documents (MID) [77]. The MID is essentially a programming language developed using SGML and HyTime that was designed to be a well­specified and unambiguous format to which data from arbitrary IETM databases can be "mapped" for interactive presentation [78, 77]. MID developers refer to the MID as a scripting (as opposed to a programming) language [63] and IETM data can be "scripted" in three different ways:  by directly placing IETM data within MID-defined SGML tags, by pointing to IETM data that reside in an external source, or by querying an external source that contains IETM data.

The MID effort was initiated by Carderock Division Naval Surface Warfare Center (CDNSWC) in early 1994. With the initiation, funding was obtained and a MID committee was formed. The original MID committee included both Government and industry representatives. By December 1994, they had produced a draft MID specification (dated November 1994), the MID SGML DTD, and two limited prototype MID processing and presentation systems that both run under Microsoft (MS) Windows 3.1.

During 1995, a new MID effort led by the Naval Air Warfare Center Aircraft Division (NAWCAD) in St. Inigoes, MD, began. The goal of the new MID effort has been to refine and improve the original MID DTD. In addition to this, they intend to provide software that can process and present data encoded in accordance with the new MID DTD.

The main issue here is whether the MID constitutes a suitable view package specification for IETMs prepared in accordance with the IETM specifications. The content-specific layer DTD for Organizational-level (O-level) maintenance (coupled with the generic layer DTD) in MIL­D­87269 is itself a programming language defined in SGML/HyTime. The MID is also a programming language in SGML/HyTime (although it bears little resemblance to MIL­D­87269). Two major IETM system implementations associated with the F­16 and the F/A­18 show little or no separation between IETM database data and IETM view package data. This contrasts with using something like the MID that would result in a comparatively large separation between IETM database data and IETM view package data.

Implementations such as the LM 2500 Gas Turbine Systems IETM utilize a view packaging method in a way that is similar to how the MID is supposed to be used. In that case, however, the data that gets "scripted" is encoded using a very simple "Class 2" DTD. This "Class 2" DTD is not nearly as complex as the O-level DTD in MIL­D­87269.

The issue is whether the MID constitutes a suitable view package specification for IETMs prepared in accordance with the IETM specifications. The MID certainly appears suitable for encoding behavior associated with interactive electronic documentation, in general, but the question is whether it is suitable to be used with the current set of DoD IETM specifications. Given the complexities associated with typical programming languages, is it economically feasible to implement one on top of another? If some major implementations that are attempting to comply with the IETM specifications show little or no separation between IETM database data and IETM view package data, then should the requirements necessary for consistent view packaging instead be imbedded more seamlessly within the requirements and DTDs in MIL­D­87269? Is something like the AMA/Softquad IETM Viewer, mentioned earlier, more appropriate for DoD IETMs built in accordance with the IETM specifications?

2.4  Conversion

The complexity and cost associated with converting data from a source format (or structure) to a target format are governed, principally, by the difference in information richness between the source and the target [7, 8]. Given that most current implementations that attempt to comply with MIL­D­87269 use the O­level DTD, there is a very large difference in information richness between most legacy sources and the O­level DTD. Simply put, this means that when developing O­level IETMs, conversion of legacy data to a degree of information­richness consistent with the O­level DTD in MIL­D­87269 is currently an expensive proposition.

The issue here is that because there are few new-start programs, should a set of IETM specifications be made more suitable for use in a legacy environment [79]? If the CDM methodology is retained, should an additional (less complex and less content-intensive) content­specific layer be designed that is more suited to this legacy environment?

2.5  IETMs and Training

From a technical perspective, there are no profound differences between the requirements necessary for developing, maintaining, and presenting electronic training materials (e.g., electronic Instructor Guides, electronic Trainee Guides, and Interactive CourseWare (ICW)) and IETMs. Also, training materials generally contain many references to TMs/ETMs/IETMs and TM/ETM/IETM data. Given this fact and the fact that training/IETM integration is receiving increasing attention, should a non-defense (or defense) specification or standard for IETMs also address training (and hence be renamed)?

In terms of the current set of IETM specifications, there is no reason why a content­specific layer for training materials (in accordance with MIL­D­87269) cannot be developed. In addition, development of such a content­specific layer may encourage the development of systems that can process arbitrary content­specific layer DTDs (assuming system implementors will want to handle at least one other content­specific layer DTD, such as the O­level DTD).

2.6  Hypermedia Information Systems Committee

• Tri-service perspectives on hypermedia,
• An IETM architecture, and
• Standards applicable to IETMs.

2.6.1  Tri-Service Perspectives

• Avoid slow developing, tight specifications for fast moving technology,
• Get and retain vendor participation, and
• Drive technology, not follow.

In addition, in the Navy presentation, the following hypermedia functional requirements were proposed:

• Links to other data, documents, databases, applications, ICW, media,
• Transparent, seamless, invisible retrieval/linking across operating systems, application software, etc.,
• Links by function (train, supply, etc.),
• Expanded communications and connectivity,
• Remote video diagnostics, maintenance support, and training, and
• World Wide Web (WWW)/Internet like functionality.

The tri-service perspectives must be taken into account when investigating various alternatives to migration of the IETM specifications. In terms of the DoD IETM specifications, little in the way of vendor participation has occurred. Additionally, with respect to the functional requirements listed above, although it is within the realm of capabilities provided by the CDM, no notable attempt has been made to extend the IETM specifications (particularly MIL­D­87269) to anything beyond technical manuals.

2.6.2  IETM Architecture

The functional architecture defines what is typically called a system framework. The framework supports an object­oriented multimedia system. While the use of the object­paradigm to represent content is debatable, the use of it to provide the underlying software framework is not. The object-oriented framework approach to software systems is a known and well­understood technology that can support IETM systems now and for the foreseeable future.

1. Each component in the framework has been optimized to do a particular task efficiently, yet with a design that enables expansion of its capabilities as warranted with a minimal impact on other components in the system.
2. Common functionalities are shared throughout the framework. A typical object­oriented framework has a core class library that provides basic services common to all applications built on them. All frameworks provide classes for creating windows, handling keyboard and mouse events, reading and writing files, etc.

An advanced IETM functional architecture based on a framework is provided in Figure 2.6.2-1.

The IETM system architecture components are as follows:

• Editors ­ content editors for notations (different data types) used within the IETM system. Content editors may interact directly with the Viewing Framework (e.g., a browser) for creating document instances prior to their registration in the database management system typically for prototyping or creating private objects.

• Viewer Framework ­ an IETM display management engine with applications that support display and navigation of notations such as SGML, Virtual Reality Modeling Language (VRML), Computer Graphics Metafile (CGM). This can be realized as
  1. An integrated application in which a single IETM application has the display and rendering software for all of the notations referenced within an IETM, a.k.a, the Swiss­Army knife application.
  2. A configured application environment in which peer applications known as cooperative applications exchange messages and some data to navigate technical information.
  3. An IETM framework application that calls other applications (helpers or plug­ins) to display and render other notations. These can be called from the IETM framework application but may share common functionality such as network and database access through a management library, or may run independently.
  4. All of the above.

   

   

  

   

  Figure 2.6.2-1  IETM Functional Architecture
  

   

• Network Communications Layer ­ a layer for providing interfaces to network applications. This may include proxies for multiple protocol handlers and firewall applications. Note that network layers are not required for all IETM applications. For example, Portable Maintenance Aid (PMA) applications typically run in a standalone mode. However, there are scenarios for PMAs that include the use of a central server which downloads the IETM information to the PMA prior to its use in the field. Therefore, the network interfaces can still be considered fundamental components of IETM systems.

• DataBase Management System (DBMS) ­ management software for ensuring consistency of the underlying content type databases. It may include security features and must interact through firewalls. As shown in Figure 2.6.2­1, the Database Management System is an optional feature of an IETM system. Although it may be part of the IETM delivery environment, this is an option.

• Hybrid Object/Relational Databases ­ database(s) for the internal structures that store content type data. A Hybrid Object/Relational model is shown because it is capable of managing both semantic relationships and non-table objects such as SGML objects, VRML objects, etc. Although a database system may be part of the delivery environment, this is an option.

These components are matched for different applications. For example, authoring system support may require many of the same components as a viewing system for distributed hypermedia documents (e.g., a World Wide Web application) given that the authoring system must support concurrent, distributed authoring tasks. The viewer used to deliver the IETM to the end user is also part of the validation tools for authoring, etc. As mentioned above, not all IETM systems use DBMS and database components.

A framework for IETMs is unique only in its focus on IETM functionalities that are not found in other multimedia systems. For example, clocks and timing are fundamental to multimedia class libraries, but interfaces to external test devices are not. Multimedia notation types (bitmaps, video, audio) must be supported by any multimedia class library and hide the details of storing, retrieving, and presenting media to the user. IETMs with a requirement for interoperating with other weapons system components must use standard notations.

This lower-level functionality of the supporting systems (e.g., communications, database management) can be divided into modular object libraries. For example, the protocol handling code for a MIME library might be in a separate, dynamically linked library as might the rendering and navigation routines as well as caching routines for immediate access to recently retrieved information such as graphics. Modular function libraries and plug-ins can be useful when, for example, a notation processor such as an intelligent CGM player must perform a common function such as accessing a network through a common protocol (e.g., File Transfer Protocol [FTP]) to retrieve information.

2.6.3  Standards Applicable to IETMs

Within this draft TCAP, the technical aspects of IETM development and delivery are divided into four distinct functional categories:

• Data (the underlying content-oriented data),
• Script (the logic or behavior within IETMs),
• Package (identifies grouping, timing, location, etc.), and
• Render (deals with the presentation of the "packaged" data).

With each of these categories, the TCAP requests that appropriate standards and/or specifications be identified that fulfill the requirements of each category. Following this, the TCAP requests that between those standards and/or specifications, associations be determined that both are application-oriented and satisfy the requirements of different functional categories.

      

3.1  Approach

1. A specification for the look and feel of electronic maintenance documentation,
2. A generalizable database specification, and
3. A quality assurance specification.

As a result of conducting various fact-finding efforts for this and other projects, it has become apparent that at this time, within DoD and industry, there is not substantial agreement as to what a complete set of military IETM specifications should consist of. This fact is illustrated by the issues discussed in a previous section and those that will be discussed later (e.g., MIL­D­87269 CDM versus MIL­PRF­28001 PS, MIL­STD­2361, etc.). It is safe to say only that for each IETM specification (including MIL­Q­87270), there are both opponents and proponents.

Because complete agreement on the IETM specifications does not exist, the position has been taken (by those involved in the authoring of this report) that it is not clear what should be in a complete set of non­defense IETM standards or specifications and therefore some effort will be devoted to shedding light on what a set of non­defense IETM standards or specifications should consist of. To this end, the analysis of migration alternatives has focused on the following generic aspects of the IETM planning, development, and deployment processes:

• Authoring and maintaining digital data for electronic technical manuals,
• Electronic presentation of maintenance information and IETM data,
• Provisions for validating prepared ETMs and underlying ETM data sets,
• Interchange of ETMs and ETM database data, and
• Roadmap between an ETM database or data set and the compiled/formatted executable ETM.

These aspects are spelled out more specifically in Table 3.1­1.

Note that the set of generic aspects listed in Table 3.1­1 was constructed in accordance with the assumption that the database development and view packaging processes are separable. A distinct separation is favored by some DoD IETM implementations. By focusing on the items in Table 3.1­1, the associated analysis will attempt to identify and evaluate:

1. Where the DoD IETM specifications currently fit into these processes and how they are used.
2. Where candidate non-defense ETM/IETM standards/specifications fit into these processes.
3. How the IETM specifications compare to non-defense approaches at fitting into these processes.
4. What processes cannot be adequately addressed by a non-defense standard.

This analysis was designed as a tool to help decide between two principal alternatives. The first is the incorporation of the IETM specifications within an appropriate commercial, national, or international standard or specification. The second is the creation of a new commercial, national, or international standard or specification through direct transformation of MIL­M­87268 and/or MIL­D­87269 and/or MIL­Q­87270. Due to the nature of the IETM specifications and the state of current ETM/IETM implementations, there is no straightforward evaluation method for determining which of these alternatives is most appropriate for migration.

To perform the evaluations and to provide data for making the decisions discussed above, a four­phase analysis has been conducted. In the first phase, non­defense standards and specifications that are applicable to electronic maintenance documentation were identified. In the second phase, the capabilities provided by the candidate standard(s) were identified. In the third phase, the question of whether, and to what extent, the candidate standard's capabilities could be considered a functional equivalent to, or a subset of, any or all of the items in Table 3.1­1 was determined. During this phase, conflicts between the candidate standard's capabilities or requirements and the IETM specifications were also identified.

The third phase was somewhat subjective and required that each item in Table 3.1­1 have some method by which its presence, absence, and degree of similarity to the IETM specifications could be determined. Appendix A addresses each item in Table 3.1­1 for the purpose of showing how detailed sets of criteria can be constructed to aid in the identification and evaluation of the items in Table 3.1­1. To aid in not only evaluating a selected standard or specification but also comparing it to the IETM specifications, the items in the appendix contain selected requirements from the IETM specifications, where appropriate. Note also that from these items, it becomes apparent which of the generic aspects in Table 3.1­1 are addressed by the IETM specifications and which are not. For each identified standard or specification, the third phase was completed when Table 3.1­2 was filled out. The tables for the identified non­defense specifications/standards are given in later sections devoted to the non­defense specifications/standards.

In the fourth phase, the set of capabilities and conflicts identified in the second and third phases were evaluated and some determination made as to whether there are missing capabilities that could be provided by incorporating one or more aspects of the IETM specifications. The results of this phase are also in later sections devoted to the non-defense specifications/standards.

3.2  The DoD IETM Specifications

      

4.1  Defense

4.1.1  The Original Tri-Service IETM Roadmap

1. Electronic Display Device (EDD) Requirements Handbook (2nd Quarter (Q) Fiscal Year (FY) 1995),
2. Acquisition Manager's Implementation Handbook (2nd Q, FY 1996),
3. Detailed IETM course material (3rd Q, FY 1995),
4. View Package Handbook (2nd Q, FY 1996),
5. Revised MIL-M-87268 (3rd Q, FY 1996),
6. Revised MIL-D-87269 (3rd Q, FY 1996), and
7. Revised MIL-Q-87270 (3rd Q, FY 1996).

However, the issuance of the Perry Memo, among other things (including lack of funding), seems to have placed both the TSWG and their plans for completing the "tasks" and products outlined in the roadmap in a state of limbo.

In accordance with the roadmap, the products listed above were to have been developed in a carefully executed fashion such that inputs from the Army, Navy, and Air Force would all be taken into account. All development was to begin through service-specific studies and the development of service-specific guidance documentation. The resultant service-specific products were then to be harmonized through various meetings and workshops (e.g., EDD requirements workshop, Acquisition Managers Guide workshop, MIL-M-87268 revision workshop, content requirements meeting). The final result of all of this would presumably have been a complete, agreed upon, and much needed set of IETM specifications, handbooks, and guidance documentation for the three services.

When considering the migration of the DoD IETM specifications to a non-defense standard, tri­service consensus must be obtained. In addition, a carefully conceived plan (such as that outlined in the TSWG IETM roadmap) must be formulated that will satisfy both:  standardization requirements and individual service requirements. Given the current state of acquisition reform, it is recommended that this roadmap be revised in accordance with the recommendations given at the end of this report.

4.1.2  Performance Specifications

1. Eliminating QA requirements,
2. Aligning style and format to MIL-STD-961D,
3. Emphasizing results rather than procedures to achieve results, and
4. Reducing instructions for IETM types.

In MIL-D-87269, the main changes will be

1. Eliminating QA requirements,
2. Aligning style and format to MIL-STD-961D,
3. Emphasizing results rather than procedures to achieve results,
4. Incorporating Amendment 1 with HyTime compliant linking,
5. Adding additional descriptive information to appendices C and D, and
6. Focusing more on cosmetics than on procedure.

The performance-specification approach to defense-oriented standardization is occurring due to the Perry Memo. The IETM specifications, including MIL­Q­87270, were actually performance specifications, to a large extent, before the Air Force found itself in the position of essentially being required to undertake this "conversion" (so that Air Force programs could use them). This action does not resolve the issues associated with MIL­M­87268 and MIL­D­87269 that are given in a previous section (or those to be identified later).

In obtaining recommendations for defense and non-defense standardization during this task, it was discovered that there are those, particularly in the DoD IETM community, who question whether performance specifications, in accordance with current acquisition reform, are appropriate for IETMs. The fact is that the DoD IETM specifications have existed somewhat as "performance" specifications since being issued in 1992. If the DoD IETM specifications were adequate prior to conversion, then they should be adequate following conversion (although without MIL­Q­87270). The issues given in a previous section, however, indicate that the DoD IETM specifications have been, and following conversion will likely continue to be, inadequate (at least in terms of portability and interoperability). In the case of MIL­D­87269, more detail is required if portability and interoperability are to be achieved, and it should be possible to provide the additional detail in "what is necessary" terms [14] (and still satisfy the requirements for being a performance specification).

4.1.3  MIL-D-87269 and MIL-PRF-28001

Both MIL­D­87269 and MIL­M­28001 specify the use of SGML for data exchange. In terms of differences, MIL­D­87269 was designed for the purposes of exchanging entire databases of format-free weapons system maintenance information (when the data are to be delivered to the Government), whereas MIL-M-28001 was designed for the purposes of exchanging document­specific data that was destined for page-oriented hardcopy display (due to the FOSI requirement). More specifically then, one principal difference is that MIL­D­87269 does not require a FOSI with output processing information. Another difference is that MIL­M­28001 does not require that DTDs conform to anything equivalent to the generic layer DTD in MIL­D­87269.

The recommendations in Reference 15 call for combining these two specifications into a single unified specification. The major concern in this document is enabling a degree of compatibility such that any presentation/delivery system can operate on both. To support this, it is recommended that some method be developed for including formatting instructions with MIL­D­87269 data. The other major concern is that MIL­D­87269 be extended to other forms of data, beyond technical manuals (e.g., training materials, reports, etc.).

At this time, the fundamental boundaries that have separated MIL­D­87269 and MIL­M­28001 are beginning to disappear. In the case of MIL­M­28001, a recent draft of MIL­PRF­28001 [17] contains an additional new OS specifically for electronic and interactive electronic display. The extra new OS is termed the PS and an instance is termed a Formatting Presentation Specification Instance. In the case of MIL­D­87269, on the other hand, a lot of attention is being paid to methods for presenting CDM­compliant IETM data. The MID is a good example of this.

It is not currently clear what should be done concerning the unification of MIL­PRF­28001 and MIL­D­87269. In the case of MIL­PRF­28001, the future of the OS and PS is not clear, due to the Document Style Semantics and Specification Language (DSSSL). The OS was never widely implemented, DSSSL is expected to have a broad support base among the vendors, and it is not clear that vendors will seek to implement the PS. In the case of MIL­D­87269, the future of the CDM concept is not clear given the issues described previously, coupled with the lack of vendor support.

The only thing that is clear concerning the issue of MIL­D­87269 and MIL­PRF­28001 is that there is a lack of notable vendor support for both. A non-defense standard or specification for IETMs should not be developed without some level of harmonization, integration, and/or cooperation between the parties responsible for each of these specifications. A unified position on the part of DoD should be obtained.

4.1.4  The Role of MIL-STD-2361

MIL­STD­2361 will contain DTDs, FOSIs, and tag descriptions, as well as interface and integration instructions. The DTDs, etc., are being designed to apply to both new and legacy data. Once complete, MIL­STD­2361 will be classified as an interface standard that will be mandatory within the Army.

As of this writing, more detailed information (i.e., an actual draft of MIL­STD­2361) has not yet been obtained. MIL­STD­2361 is intended to be a defense interface standard that addresses all Army publications, including IETMs. At this time, however, it appears that the IETM­related DTDs are being based on a work package concept with no requirements to conform to the CDM in MIL­D­87269. It is not clear how this will affect future DoD IETM standardization initiatives (including non­defense standardization). If the DTDs do not conform to the CDM, then the MIL­STD­2361 effort will likely complicate matters.

4.1.5  Modification and MID Inclusion

These ideas are included within this report because they constitute possibly the first set of documented, publicly available ideas that describe an actual integration between MIL­M­87268, MIL­D­87269, and MID. Furthermore, these ideas are presented as coming together within the context of a performance specification (thus satisfying the requirements of acquisition reform). In addition, these ideas can be extended. Specifically, a further step for the purposes of harmonization could be to simply register the IETM/MID output layer as an alternative output specification within MIL­PRF­28001, thus having three variant OSs (some more appropriate for a given circumstance than others) rather than two (the DSSSL may eventually constitute a fourth possibility).

4.1.6  IETMs and Logistics Support Analysis Record

A strategy for migration of the IETM specifications to a non-defense standard or specification should give some consideration to integration with the results of Logistics Support Analysis (LSA), thus contributing to an Integrated Logistic Support (ILS) capability. One example of a defense standard that has been designed (and is still evolving) specifically for ILS is Ministry Of Defense (MOD) Defense Standard 0060 within the United Kingdom (U.K.). As MOD­0060 evolves, it is expected to use the following standards/specifications as its basis [33, 34]:

1. MIL-STD-1388-1A - LSA,
2. MIL-STD-1388-2B - LSAR,
3. AECMA 1000D Electronic Documentation, and
4. AECMA 2000M Integrated Supply Support Procedures.

One problem faced by MOD­0060 is a result of acquisition reform within the U.S. DoD. Specifically, MIL­STD­1388­1A will be canceled after the development of a handbook, and MIL­STD­1388­2B will be canceled after being transformed into a performance specification [35]. The transformation of MIL­STD­1388­2B will result in the disappearance of data (e.g., entire task­related tables) that has previously been used for integrating LSAR and IETMs. The rationale behind these eliminations is that task information is better left in the technical manual (one reason provided for this was that revisions are usually made to the TM first and do not always get reflected back in the LSAR).

At this time, one reasonable non-defense strategy for integrating IETM development with LSA is through the ISO STEP effort. More on this is provided in Section 4.2.3 of this report.

4.2  Non-Defense

4.2.1  Direct Standardization

International standardization organizations with relevance to this task include

• International Organization for Standardization (ISO),
• Institute of Electrical and Electronics Engineers (IEEE),
• International Electrotechnical Commission (IEC), and
• International Telecommunication Union (ITU).

One national standardization organization with particular relevance to this task is ANSI.

The standardization organizations that are being further investigated specifically for this task include ANSI and ISO.

4.2.1.1  ANSI

Submission of a proposed American National Standard (ANS) requires that the developer of the proposed standard be accredited by ANSI. To achieve this, there are two options. The first is to develop and/or process the proposed standard through a currently accredited ANSI standards developer. The second is to directly seek ANSI accreditation as a standards developer.

For the first option, ANSI suggests that the following standards developers are currently accredited (through ANSI) to develop standards for areas that include IETMs:

Data Interchange Standards Association
1800 Diagonal Road, Suite 200
Alexandria, VA 22314
(703) 548-7005

Standards Secretariats
1250 Eye Street, NW, Suite 200
Washington, DC 20005
(202) 737-8888

Institute of Electrical and Electronics Engineers (IEEE)
Standards Department
445 Hoes Lane
Piscataway, NJ 08855-1331
(908) 562-3800

American Society for Testing and Materials (ASTM)
1916 Race Street
Philadelphia, PA 19103-1187
(215) 299-5400

According to ANSI guidelines, a standards developer may be accredited to use one or more recognized methods for developing or ascertaining consensus. Three recognized methods, approved by ANSI, are

1. Accredited Standards Committee Method,
2. Accredited Canvass Method, and
3. Accredited Organization Method.

In the Accredited Standards Committee Method, standing committees of directly and materially affected interests are created to establish consensus for a proposed standard [36]. This method is typically used when the proposed standard affects a broad range of diverse interests, or where multiple associations or societies with similar interests exist [37]. ANSI has a set of model procedures, consistent with ANSI accreditation guidelines, that can be used by any developer who wishes to adopt this method [36].

In the Accredited Canvass Method, small trade associations or societies that follow a set of documented industry practices can have these practices standardized as an ANSI standard [36]. When using this method, the developer must identify, to the extent possible, those who are directly and materially affected by the proposed standard and conduct a letter ballot or "canvass" of those interests for the purpose of obtaining consensus [37]. As in the committee method, ANSI has a set of model procedures, consistent with ANSI accreditation guidelines, that can be used by any developer who wishes to adopt this method [36].

In the Accredited Organization Method, standards are developed by associations and societies that simply have an interest in doing so [37]. Participation on the consensus body for a standard, proposed through this method, is open to all interested parties and is not restricted to those within the association or society. This method differs from the previous two in that there are no model procedures provided within ANSI guidelines. Although this is the case, accreditation requires conformance to ANSI's due process requirements, etc.

The process for initiating and seeking approval of a proposed ANSI standard consists of four steps [38]:

1. Project Initiation Notification System (PINS) forms,
2. Initiation of Public Review (Board of Standards Review (BSR)-8 form),
3. Consensus Ballot, and
4. Final Submittal (BSR-9 form).

When initiating the development of an ANSI standard, proposals are sent to ANSI under their Standards Activities Tracking System, using the PINS form. Then, the proposed standardization initiative is listed in ANSI's "Standards Action" publication (a biweekly newsletter) for public comment [38]. This phase may have a direct effect on the eventual development of the standard because it may result in the identification of other potentially overlapping standardization initiatives.

Once a draft of the proposed standard has been completed, a BSR­8 form must be submitted by the accredited developer. Completion of this form initiates a 30 to 60 day public review and comment period through Standards Action. This period can last for a minimum of 30 days if the standard can be published in full [38]. The developers must respond and attempt to resolve all comments received during the review and comment period.

The next step in the standardization process involves completion of a consensus ballot. The purpose of this ballot is to show that substantial agreement has been reached by an appropriate consensus group. All objections must be addressed by the developer.

Once consensus has been achieved, a BSR­9 form is completed and is submitted with the standard to ANSI for approval. The accredited developer has six months from the close of public comment and review to submit the BSR­9 form. Submissions with no outstanding objections are sent to the BSR for final approval.

4.2.1.2  ISO

ISO covers all standardization fields except electrical and electronic engineering (which is covered by the IEC). Given ISO's prominent position in international standardization and its coverage, it is appropriate for consideration for non­defense standardization of IETMs. Within the ISO hierarchy of committees and advisory groups, an appropriate technical committee for dealing with non­defense IETMs is the ISO/IEC Joint Technical Committee (JTC)­1. Currently, JTC­1 has 245 ISO standards and Draft International Standards (DIS) under its responsibility with 26 participating countries and 34 observer countries [39]. In addition, there are 1,042 ISO standards and DIS related to the work within JTC­1.

One candidate subcommittee (SC) within JTC­1 for non-defense IETM standardization is SC­18. SC­18 deals with document processing and related communication. There are currently 81 ISO standards and DIS under the responsibility of SC­18. These standards include

• SGML, ISO 8879:1986,
• HyTime, ISO/IEC 10744:1992,
• DSSSL, ISO/IEC DIS 10179,
• Standard Page Description Language (SPDL), ISO/IEC 10180:1995,
• Open (Office) Document Architecture (ODA), ISO 8613-1:1989,
• Standard Music Description Language (SMDL), ISO/IEC DIS 10743, and
• SGML Document Interchange Format (SDIF), ISO 9069:1988.

Another candidate subcommittee within JTC­1 for non-defense IETM standardization is SC­29. SC­29 deals with the coding of audio, picture, multimedia, and hypermedia information. There are currently 22 ISO standards and DIS (including Coding of Multimedia and Hypermedia information (MHEG), ISO/IEC DIS 13522) under the responsibility of SC­29.

There are two main avenues for developing an ISO standard:  the six step process and the fast­track procedure. The stages in the six step process are as follows [40]:

Stage 1:  Proposal stage,
Stage 2:  Preparatory stage,
Stage 3:  Committee stage,
Stage 4:  Inquiry stage,
Stage 5:  Approval stage, and
Stage 6:  Publication stage.

In the staged approach, Stage 1 involves the determination as to whether a particular international standard is needed. This involves the development of a new work item proposal (by members of an appropriately chosen Technical Committee (TC) and SC, a national member body, or an advisory group to the ISO Technical Management Board, etc.) [41]. Acceptance of the proposal requires that a majority of the participating members (P­members) of the involved TC or SC are in favor and at least five (or in some cases more) P­members elect to participate in the standardization effort.

In Stage 2, a working draft, possibly through the establishment of a working group, is prepared. In the ISO/IEC directives, it is a requirement that every possible effort be made to develop both an English and a French version.

Stage 3 is essentially a consensus building stage. National bodies provide comments, and successive drafts are issued until there is consensus (or an agreement to abandon or postpone the work item) among the P­members of the TC or SC. If a consensus is reached, the standardization document is finalized and submitted as a DIS.

In Stage 4, the DIS is distributed to all ISO member bodies for voting and comment. Disapproval could result in the development of revisions and redistribution. Approval ultimately results in the DIS being reclassified or transformed into a FDIS.

In Stage 5, the FDIS is distributed to all ISO member bodies for final approval. Approval as an ISO standard is obtained if two­thirds of the P­members are in favor and no more than one­fourth of all votes cast are against. In Stage 6, the ISO standard is published through the ISO Central Secretariat.

4.2.2  Incorporation Within an Existing Standard

1. AECMA Specification 1000D (International Specification for Technical Publications Utilizing a Common Source Database, Change 6),
2. ATA Specification 2100 (Digital Data Standards for Aircraft Support, Revision 0, 1/94), and
3. J2008 SAE Draft Technical Report, Recommended Organization of Vehicle Service Information, March 1, 1995).

These were selected as a result of recommendations from representatives in both DoD and industry. The harmonization of AECMA 1000D and the DoD IETM specifications has been under consideration for some time. In particular, at the Acquisition Logistics Standards Harmonization Assessment Workshop sponsored by the NATO Armaments Committee 301 Subgroup D on CALS, it was deemed technically feasible at that time (i.e., March and April 1993), to harmonize and integrate various relevant standards and specifications, including AECMA 1000D and the DoD IETM specifications [29]. In addition, ATA 100, which previously contained requirements for digital data exchange (and have been relocated to ATA 2100), and J2008 have both been previously scrutinized in a feasibility study concerning the use and migration to non-defense standards and specifications [44]. The analyses done in that work, however, were not with respect to the DoD IETM specifications.

4.2.2.1  AECMA 1000D

In addition to providing documentation-specific requirements, AECMA 1000D defines an information database. The information database, once developed, provides the source information that is used within the technical documentation. Additionally, the information database may also be used in an electronic logistics information system such that "modules" of information can be delivered directly to a user.

The development of 1000D was conducted through task groups that were established by the Augmented Documentation Working Group (ADWG). The ADWG was in turn established by a Documentation Working Group (DWG) which was itself established by AECMA's Product Support Commission (PSC). One of the primary sources that was used by the ADWG in the development of AECMA 1000D is ATA 100. Additional source documents consisted of various U.S. military specifications, including MIL­M­28001, MIL­M­87268, and MIL­D­87269.

AECMA 1000D has been considered by both the U.S. Navy and Air Force to be a prime candidate for achieving a non­defense specification applicable for the development of U.S. DoD IETMs. In the analysis that was conducted on AECMA 1000D (Change 5) for this migration task it became evident that on the basis of the requirements given in 1000D alone, this was indeed the case. Following the initial analysis, however, AECMA released Change 6 to 1000D. Change 6 contains 1000D's most up-to-date set of requirements. As will be discussed in detail later, the inclusion of the newest set of requirements within Change 6 has resulted in a conflict between the way Interactive Electronic Technical Publications (IETP) data is structured/handled through the Data Module (DM) concept in 1000D compared to the way in which IETM data is structured/handled through the CDM in MIL­D­87269.

4.2.2.1.1  Organization

1. Introduction,
2. General Rules,
3. Common Source Database, and
4. Technical Publications.

The chapter entitled General Rules provides general guidelines governing high­level developmental considerations, such as

• Standard numbering system,
• Writing rules,
• Illustration rules,
• Warnings, cautions, notes,
• Security classification, and
• Quality assurance.

One provision, within the subchapter on writing rules, and appropriate for an international standard, concerns language. In particular, when procedural instructions are written in English, they must be written in AECMA Simplified English (SE). One of the noted advantages of using AECMA SE is that its use enables easier and cheaper translation among languages.

The Common Source Database (CSDB) chapter provides the specifications for establishing and operating the CSDB. The CSDB revolves around the data module concept. Within this section the DM structure is presented as well as rules for

• Interchange of data modules,
• Document Type Definition,
• Output Specification (OS), and
• Updating of Data Modules.

Note that although a chapter exists specifically to address the OS, it has not yet been completed. Within 1000D, it is stated that the OS chapter will essentially be empty until a common approved international standard is available. The intent of the chapter is to ultimately provide OS guidelines for both page­oriented and interactive electronic technical publications. The DSSSL standard (ISO 10179), including its subsets (especially DSSSL­Core (formally DSSSL­Lite)), may fulfill, either in whole or in part, the guidelines envisioned by 1000D developers.

The chapter entitled "Technical Publications" includes content, format, and updating guidelines for technical publications. The format for presentation of both paper and screen, page­oriented presentation, is given. There are also subchapters on interactive electronic technical publications. Additionally, this chapter includes subchapters/sections on:

• Information sets,
• Contents of information sets,
• Development of content that is specific to air vehicles,
• Preparation of common information and data information,
• Format of publications,
• Page-oriented publications,
• Layout of paper publications,
• Typography for paper publications,
• Examples of paper publications,
• Coding of publications, and
• Updating of publications.

4.2.2.1.2  Data Modules and MIL-D-87269

DMs contain two main categories of information:

• Content and
• Address and status information.

For the purposes of highlighting some of the more overt differences between the DM concept and MIL­D­87269, consider the content section. Content sections contain two main categories of information:

• References and
• Marked section.

Marked sections can contain one of the following information types:

• Description,
• Procedure, and
• Other (to be defined),
  Maintenance schedule information,
  Fault isolation information, and
  Wiring data and schematic diagram information.
  

When attempting to compare 1000Ds data module concept to MIL­D­87269, correlations are readily apparent when comparing the DM to the content-specific layer DTD in MIL­D­87269 for Organizational­level (O­level) maintenance. Specifically, as currently defined, DMs can provide data whose scope resembles that of the <task> and <descinfo> elements in the O­level DTD. In addition, in contrast to what is found in MIL­D­87269 and the generic and O­level DTDs, DMs do not currently define the handling of

• Fault information (yet to be defined),
• Part information (this is left to AECMA 2000M),
• Variables,
• Expressions, and
• Conditional branching.

The way in which data is organized and accessed also differs somewhat between 1000D and the O­level DTD in MIL­D­87269. In 1000D, data organization and system hierarchy are delineated with a Standard Numbering System (SNS). Each DM has a Data Module Code (DMC) within the address/status section. The DMC contains the alphanumeric characters from the SNS. When gaining access to DMs within the CSDB, the SNS essentially represents a standard, structured address for locating and retrieving the information.

In the O­level DTD in MIL­D­87269, the organization, hierarchy, and structuring of data can be accomplished through the nesting of <system> elements. Although desirable, no standard numbering system is really required when creating data according to the O­level DTD. Because there is currently no similar concept of a recursive system element in the DTDs within 1000D (that can contain hierarchical groups of DMs), coherent organization of data in 1000D essentially requires some sort of SNS for the system in question.

In addition to these differences, the DM concept within 1000D differs from MIL­D­87269 at a much more fundamental level. In MIL­D­87269, the two principal requirements that highlight this difference (provided earlier in the document but repeated here for convenience) are Requirements 3.1.4 and 3.2:

3.1.4  Additional content specific DTDs:  When specified, additional content specific DTDs shall be used in addition to or instead of the content specific DTD defined in Appendices B and D of this specification (see 6.2). These DTDs shall be incorporated into the overall CDM in accordance with the requirements of 3.2.

3.2  Generic layer:  The generic layer of the CDM is defined in the DTD listed in Appendix A. This DTD provides templates, which shall be used to define content specific elements. The generic layer includes a definition for each template and the attribute lists associated with the template. The DTD provides a definition of three other data types: primitive data elements that shall remain standard across all content specific applications; user interaction elements, called dialogs; and the context filtering elements, which shall be used to provide the most appropriate information to a user.

As described earlier in this document, Requirement 3.2 states that the templates given in the generic layer DTD shall be used to define content-specific elements (and therefore governs the development of any content-specific layer DTD). These templates are classified as Node, Node Alternatives, Node Sequence, If Node, and Loop Node. In addition, the generic layer DTD contains primitive data elements, user interaction elements, and context filtering elements, etc. Although a DM is in some sense generic, there is nothing equivalent in 1000D to the generic layer concept, the generic layer DTD, or to the above requirements.

4.2.2.1.3  Interactive Electronic Technical Publications

4.4.1 "Page-oriented Publications,"
4.4.2 "Interactive Electronic Technical Publications (IETP) - General,"
4.4.3 "Interactive Electronic Technical Publications - Linearly structured (IETP-L),"
4.4.4 "Interactive Electronic Technical Publications - Database oriented (IETP-D)," and
4.4.5 "Interactive Electronic Technical Publications - Integrated process (IETP-I)."

The Page-oriented