# JTA SECTION 2 - INFORMATION PROCESSING STANDARDS

DATE REVISED: 22 AUGUST 1996

SECTION 2 INFORMATION PROCESSING STANDARDS

- 2.1 INTRODUCTION
- 2.1.1 Purpose
- 2.1.2 Scope
- 2.1.3 Background
- 2.2 MANDATES
- 2.2.1 Application Software Entity
- 2.2.2 Application Platform Entity
- 2.2.2.1 Service Areas
- 2.2.2.1.1 Software Engineering Services
- 2.2.2.1.2 User Interface Services
- 2.2.2.1.3 Data Management Services
- 2.2.2.1.4 Data Interchange Services
- 2.2.2.1.5 Graphic Services
- 2.2.2.1.6 Communications Services
- 2.2.2.1.7 Operating System Services
- 2.2.2.2 Application Platform Cross-Area Services
- 2.2.2.2.1 Internationalization Services
- 2.2.2.2.2 Security Services
- 2.2.2.2.3 System Management Services
- 2.2.2.2.4 Distributed Computing Services
- 2.3 EMERGING STANDARDS
- 2.3.1 Software Engineering Service
- 2.3.2 User Interface
- 2.3.3 Data Management
- 2.3.4 Data Interchange
- 2.3.5 Operating Systems

# SECTION 2 INFORMATION PROCESSING STANDARDS

## 2.1 INTRODUCTION

### 2.1.1 Purpose

The purpose of this section is to specify the Joint Technical Architecture (JTA) government and commercial information processing standards the DoD will use to develop integrated, interoperable systems that directly or indirectly support the Warfighter.

Information processing standards support the objectives of reducing cost and time of development, easing software integration and maintenance, and improving interoperability. The primary mechanism is the concept of a Common Operating Environment (COE) that provides a reusable set of common software services via standard application program interfaces (APIs). By building modular applications that use a common software infrastructure accessed through a stable set of APIs, as well as a standard integration approach, developers will be able to "plug and play" their applications into a centrally maintained infrastructure. The use of the standard APIs allows the COE and mission applications to be quickly integrated, and updated relatively independent of each other. The COE concept allows developers to concentrate their efforts on building mission area applications rather than building duplicative system service infrastructure software. Common standards, such as SQL to communicate with relational database management systems and Computer Graphics Metafile (CGM) to store graphics, support the objective of interoperability. Systems developed to these standards will be able to share services (retrieve authorized data from each other's databases) and data (such as an overlay). The use and evolution of the COE concept and the JTA standards it embodies, will advance the goal of building systems that are compatible, while minimizing program costs through systematic software reuse.

### 2.1.2 Scope

This section applies to mission area, support application, and application platform service software. This section does not cover communications standards needed to transfer information between systems (refer to Section 3), nor standards relating to information modeling (process, data, and simulation), data elements, or military unique message set formats (refer to Section 4).

### 2.1.3 Background

The COE Concept is described in the Integration and Runtime Specification (I&RTS), version 2.0, October 1995. The Defense Information Infrastructure (DII) COE is implemented with a set of modular software that provides generic functions or services, such as operating system services. These services or functions are accessed by other software through standard APIs. The DII COE may be adapted and tailored to meet the specific requirements of a domain. The key is that domain implementations adhere to the COE concept in that they provide standard modularized software services that are consistent with the Technical Architecture Framework for Information Management (TAFIM) Technical Reference Model (TRM) and that application programmers have access to these services through standard APIs.

The individual standards contained in this section and applicable appendices that will be used to implement a domain COE are presented within the framework of the TAFIM TRM. This reference model was intentionally generalized and does not imply any specific system architecture. Its purpose is to provide a "set of concepts, entities, interfaces, and diagrams that provides a basis for the specification of standards." The TAFIM TRM organizes software into two entities, an Application Software Entity and an Application Platform Entity. The Application Software Entity communicates with the Application Platform Entity through an API. The Application Platform Entity communicates with the external environment through the External Environment Interface (EEI). The TAFIM TRM decomposes these entities into sub-categories as shown in Figure 2-1. The application software entity and associated mandates are detailed in Section 2.2.1, while the Application Platform's seven major service areas and associated mandates are detailed in Section 2.2.2.1 . Section 2.2.2.2 defines the Application Platform Cross-Area Services and their associated mandates.

Figure 2-1. Detailed DoD TRM, Version 3.0

## 2.2 MANDATES

The DII COE, as defined in the DII COE I&RTS Version 2.0, is fundamental to a Joint Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) System Architecture (JCSA). In the absence of a JCSA, the JTA mandates that all Command, Control, Communications, Computers, and Intelligence (C4I) systems shall use the DII COE. All applications of a system which must be integrated into the DII shall be at least DII COE I&RTS level 5 compliant (software is segmented, uses DII COE Kernel, and is installed via COE tools) with a goal of achieving level 8.

The following sections provide the applicable mandates that shall be used in the selection of commercial or government off-the-shelf (GOTS) software or in the development of government software, to include the DII COE. Appendix B contains a table that summarizes the mandated standards from this section, as well as providing information on how to obtain the standards. The World Wide Web (WWW) version of Appendix B contains a link to the standard or to the organization that maintains the standard when one is available.

### 2.2.1 Application Software Entity

The Application Software Entity includes both mission area applications and support applications. Mission area applications implement specific user's requirements and needs (e.g., personnel, material, management). This application software may be commercial off-the-shelf (COTS), GOTS, custom-developed software, or a combination of these.

Common support applications are those ( e.g., e-mail and word processing) that can be standardized across individual or multiple mission areas and are the first layer of the DII COE. The services they provide can be used to develop mission-area-specific applications or can be made available to the user. The TAFIM TRM defines six support application categories: Multimedia, Communications, Business Processing, Environment Management, Database Utilities, and Engineering Support. The definitions of these categories are found in the TAFIM, Volume 2, Section 2.4.2.

The Application Software Entity includes all DoD application software. The following mandate applies:

- All system developers shall identify their common support applications and mission area applications. Mission area applications shall transition to the DII COE common support applications to the maximum extent possible.

### 2.2.2 Application Platform Entity

The Application Platform Entity is the second layer of the DII COE, and includes the common, standard services upon which the required functionality is built. The Application Platform Entity is used by the DII COE support applications and unique mission area applications software. The Application Platform Entity is composed of service areas and cross-area services. The definitions of these service areas are found in the TAFIM, Volume 2, Section 2.4.3 and 2.4.4 respectively. The corresponding mandates are provided in the following subsections.

#### 2.2.2.1 Service Areas

The TAFIM TRM defines seven service areas within the Application Platform Entity: Software Engineering, User Interfaces, Data Management, Data Interchange, Graphics, Communications, and Operating System Services.

##### 2.2.2.1.1 Software Engineering Services

The software engineering services provide system developers with the tools that are appropriate to the development and maintenance of applications.

Language services provide the basic syntax and semantic definition for use by developers to describe the desired software function.

According to DoD 5000.2-R, it is DoD policy to design and develop software systems based on software engineering principles. Additional guidance is contained in DoD Directive (DoDD) 3405.1. This mandate does not include software that is developed and maintained commercially.

##### 2.2.2.1.2 User Interface Services

These services implement the Human-Computer Interface (HCI) style and control how users interact with the system. The JTA mandates either Common Desktop Environment (CDE) Version 1.0 based on X Window System and Open Software Foundation (OSF) Motif APIs, or the applicable native windowing Win32 APIs. The following standards are mandated:

- FIPS Pub 158-1: 1993, User Interface Component of the Application Portability Profile X-Windows Version 11, Release 5
- OSF Motif Application Environment Specification (AES), Release 1.2, 1992
- OSF/Motif Inter Client Communications Convention Manual (ICCCM) for communication between Graphical User Interface (GUI) client applications
- Win32 APIs, Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers Reference Manual, 1993, Microsoft Press
- X/Open C323, Common Desktop Environment (CDE) Version 1.0, April 1995.

Refer to Section 5 for HCI style guidance and standards.

##### 2.2.2.1.3 Data Management Services

Central to most systems is the sharing of data between applications. The data management services provide for the independent management of data shared by multiple applications.

These services support the definition, storage, and retrieval of data elements from Database Management Systems (DBMSs). Application code using Relational Database Management System (RDBMS) resources and COTS RDBMSs shall conform to the requirements of Entry Level SQL. The following standards are mandated for any system required to use an RDBMS.

- FIPS Pub 127-2: 1993, Database Language for relational DBMSs.

The following API is mandated for both database application clients and database servers:

- Open Data Base Connectivity, ODBC 2.0.

##### 2.2.2.1.4 Data Interchange Services

The data interchange services provide specialized support for the exchange of data and information between applications and to and from the external environment. These services include document, graphics data, geospatial data, imagery data, product data, audio data, video data, atmospheric data, oceanographic data, and compression interchange services.

Message interchange standards are covered in Section 4.

###### 2.2.2.1.4.1 Document Interchange

These services provide the specifications for encoding data and the logical and visual structure of electronic documents. The following standards are mandated for document interchange:

- ISO 8879: 1986, Standard Generalized Markup Language (SGML), for the production of documents which are intended for long-term storage and electronic dissemination for viewing in multiple formats. SGML formalizes document markup, making the document system and processing independently. It is an architecture-free and application-free language for managing structures and is designed for full multi-media database publishing. SGML is a meta-language, providing the rules for designing and applying a system of markup tags rather than the specific set of tags.
- RFC-1866: 1995, Hypertext Mark-up Language (HTML), Internet Version 2.0, - Interchange format used by the WWW for hypertext format and embedded navigational links.

Table 2-1 identifies file formats for the interchange of common document types such as text documents, spreadsheets, and presentation graphics. Some of these formats are controlled by individual vendors, but all of these formats are supported by products from multiple companies. In support of the standards mandated in this section, table 2-1 identifies conventions for file name extensions for documents of various types. The following file formats are mandated, but not the specific products mentioned:

- All applications acquired or developed for the production of documents shall be capable of generating at least one of the formats listed in Table 2-1 for the appropriate document type.
- All organizations shall at a minimum be capable of reading and printing all of the formats listed below for the appropriate document type.

Table 2-1 - Document Interchange Formats

    Document    Standard/Vendor     Recommended      Reference

    Type        Format              File Name

                                   Extension

    Plain       ASCII Text          .txt

    Text

    Compound    Acrobat 2.0         .pdf             Vendor

    Document*   HTML 2.0            .htm             IETF

                MS Word 6.0         .doc             Vendor

                Rich Text Format    .rtf             Vendor

                WordPerfect 5.2     .wp5             Vendor

    Briefing    Freelance Graphics  .pre             Vendor

    -           2.1

    Graphic     MS Powerpoint 4.0   .ppt             Vendor

    Presentation

    Spreadsheet Lotus 1-2-3         .wk3             Vendor

                Release 3.x

                MS Excel 5.0        .xls             Vendor

    Database    Dbase 4.0           .dbf             Vendor

Note: * - Compound documents contain embedded graphics, tables, and formatted text. OLE linking complicates document interchange. Note that not all special fonts, formatting, or features supported in the native file format may convert accurately.

Note: Future versions of the JTA will address engineering and technical data standards such as Continuous Acquisition and Life-Cycle Support (CALS).

###### 2.2.2.1.4.2 Graphics Data Interchange

These services are supported by device-independent descriptions of the picture elements for vector and raster graphics. The ISO Joint Photographic Expert Group (JPEG) standard describes several alternative algorithms for the representation and compression of raster images, particularly for photographs. The standard does not specify an interchange format for JPEG images, which led to the development of the JPEG File Interchange Format (JFIF) format. JFIF is a de facto standard for exchanging images over the internet. The following standards are mandated:

- FIPS Pub 128-1: 1993, Computer Graphics Metafile (CGM)- Interchange format for vector graphics data
- JPEG File Interchange Format (JFIF), Version 1.02, C-Cube Microsystems for raster graphics data encoded using the ISO 10918-1: 1994, Joint Photographic Expert Group (JPEG) algorithm.

###### 2.2.2.1.4.3 Geospatial Data Interchange

For mapping, charting, and geodesy (MC&G) services, collectively known as geospatial services, the following standards are mandated:

- MIL-STD-2411, Raster Product Format (RPF) - DoD Military Standard used by the Defense Mapping Agency (DMA) to format raster-based digital products (e.g., Compressed Arc Digitized Raster Graphics (CADRG), Controlled Image Base (CIB), and Digital Point Positioning Data Base (DPPDB)), and is based on National Imagery Transmission Format Standard (NITFS) (MIL-STD-2500A) described below.
- MIL-STD-2407, Interface Standard for Vector Product Format (VPF) - DoD format for DMA's vector-based products used by geographic information system (GIS) and other DoD systems. VPF standard products include Vector Map (VMap) Levels 0-2, Urban Vector Map (UVMap), Digital Nautical Chart (DNC), VMap Aeronautical Data (VMap AD), Vector Product Interim Terrain Data (VITD), Digital Topographic Data (DTOP), Littoral Warfare Data (LWD), and World Vector Shoreline Plus (WVS+).
- MIL-STD-2401, World Geodetic System 84 (WGS-84) 21 March 1994 - DoD's standard global reference system developed by the DMA. WGS-84 is employed by the NAVSTAR Global Positioning System (GPS) and modern weapons and systems. Latitude and longitude data shall use WGS-84 in accordance with CJCSI 3900.01, and standard coordinate data elements as discussed in Section 4.
- For all other MC&G services (e.g., Digital Terrain Elevation Data (DTED), Digital Bathymetric Database (DBDB)) not captured in the above standards the products in DMAL 805-1A, DMA List of Products and Services, March 1994, shall be used.

###### 2.2.2.1.4.4 Imagery Data Interchange

The NITFS is a DoD and Federal Intelligence Community suite of standards for the exchange, storage, and transmission of digital imagery products. NITFS provides a package containing information about the image, the image itself, and optional overlay graphics. It was developed and mandated by ASD Command, Control, Communications, and Intelligence (C3I) for the dissemination of digital imagery from overhead collection platforms. Guidance on applying the suite of standards can be found in MIL-HDBK-1300A. The following standards are mandated for secondary imagery dissemination:

- MIL-STD-2500A, National Imagery Transmission Format (Version 2.0) for file format
- MIL-STD-188-196, Bi-Level Image Compression
- MIL-STD-188-199, Vector Quantization Decompression
- ANSI/ISO 8632: 1992, Computer Graphics Metafile (CGM) as profiled by FIPS 128 and MIL-STD-2301
- ISO/IEC 10918-1: 1994, Joint Photographic Experts Group (JPEG) as profiled by MIL-STD-188-198A. Although the NITFS uses the same ISO JPEG algorithm as mandated in section 2.2.2.1.4.2, the NITFS file format is not interchangeable with the JFIF file format.

Communication protocols for transmission of imagery are specified in Section 3.

###### 2.2.2.1.4.5 Product Data Interchange

Product Data Interchange standards will be addressed in a later version of the JTA.

###### 2.2.2.1.4.6 Audio Data Interchange

Formats for the exchange of stand-alone audio will be addressed in a later version of the JTA.

MPEG-1 audio is not a single compression algorithm but a family of three audio encoding and compression schemes called MPEG-Audio Layer-2, and Layer-3, all three of which are hierarchically compatible. The audio compression schemes are lossy, but they can achieve perceptually lossless quality. The following standards are mandated for audio in conjunction with MPEG-1 video:

- ISO/IEC 11172-1: 1993 - Encoding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbits/s -- Part 1: Systems
- ISO/IEC 11172-3: 1993 - Encoding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbits/s -- Part 3: Audio
- ISO/IEC 11172-3/Cor. 1: 1995 - Encoding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbits/s -- Part 3: Audio Technical Corrigendum.

MPEG-2 audio is intended to encode up to five full bandwidth channels (left, right, center, and two surround channels), and additional low-frequency enhancement channel, and up to seven commentary or multilingual channels. The following standards are mandated for audio in conjunction with MPEG-2 video:

- ISO 13818-1: 1996 - Generic Coding of Moving Pictures and Associated Audio Information - Part 1: Systems
- ISO 13818-3: 1995 - Generic Coding of Moving Pictures and Associated Audio Information - Part 3: Audio.

###### 2.2.2.1.4.7 Video Data Interchange

MPEG-1 provides for a wide range of video resolutions and data rates but is optimized for single and double-speed CD-ROM data rates (1.2 and 2.4 Mbits/s). With 30 frames per second video at a display resolution of 352 x 240 pixels, the quality of compressed and decompressed video at this data rate is often described as similar to VHS recording. MPEG-1 is frequently used in applications with limited bandwidth, such as CD-ROM playback or Integrated Services Digital Network (ISDN) videoconferencing. The following standards are mandated:

- ISO/IEC 11172-1: 1993 Coding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbits/s -- Part 1: Systems
- ISO/IEC 11172-1: 1993/Cor. 1:1995 Coding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbits/s -- Part 1: Systems Technical Corrigendum 1
- ISO/IEC 11172-2: 1993 Coding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbits/s -- Part 2 Video.

MPEG-2 is designed for the encoding, compression, and storage of studio-quality motion video and multiple CD-quality audio channels at bit rates of 4 to 6 Mbits/s. MPEG-2 has also been extended to cover HDTV. The following standards are mandated:

- ISO 13818-1: 1996 - Generic Coding of Moving Pictures and Associated Audio Information - Part 1: Systems
- ISO 13818-2: 1996 - Generic Coding of Moving Pictures and Associated Audio Information - Part 2: Video.

Video Teleconferencing (VTC) standards are specified in Section 3.

###### 2.2.2.1.4.8 Atmospheric Data Interchange

The following formats established by the World Meteorological Organization (WMO) Commission for Basic Systems (CBS) for meteorological data and published under the Manual for Codes, Volume 1, Part B, Binary Codes, WMO No. 306. The following standards are mandated:

- FM 92-X-GRIB - The WMO Format for the Storage of Weather Product Information and the Exchange of Weather Product Messages in Gridded Binary (GRIB) Form. GRIB was developed for the transfer of gridded data fields, including spectral model coefficients, and of satellite images. A GRIB record (message) contains values at grid points of an array, or a set of spectral coefficients, for a parameter at a single level or layer as a continuous bit stream. It is an efficient vehicle for transmitting large volumes of gridded data to automated centers over high speed telecommunication lines using modern protocols. It can equally well serve as a data storage format. While GRIB can use predefined grids, provisions have been made for a grid to be defined within the message.
- FM 94-X-BUFR - The WMO Binary Universal Format for Representation (BUFR) of meteorological data. Besides being used for the transfer of data, BUFR is used as an on-line storage format and as a data archiving format. A BUFR record (message) containing observational data of any sort also contains a complete description of what those data are: the description includes identifying the parameter in question, (height, temperature, pressure, latitude, date, and time), the units, any decimal scaling that may have been employed to change the precision from that of the original units, data compression that may have been applied for efficiency, and the number of binary bits used to contain the numeric value of the observation. BUFR is a purely binary or bit oriented form.
- Data Exchange Format (DEF) - Appendix 30 to the Tactical Automated Weather Distribution System (TAWDS)/Integrated Meteorological System (IMETS) Implementation Document for Communication Information Data Exchange (CIDE).

###### 2.2.2.1.4.9 Oceanographic Data Interchange

Standard transfer formats are required for the pre-distribution of oceanographic information. WMO GRIB and the BUFR file transfer formats are used for this purpose. The GRIB and BUFR extensions include several extensions, including provision for additional variables, additional originating models, a standard method to encode tables and line data; a method to encode grids (tables) with an array of data at each grid point (table entry); and a method to encode multiple levels in one GRIB message. There is also a possible need to incorporate a method for vector product data. The following WMO CBS format for oceanographic data use is mandated:

- FM 94-X-BUFR - The WMO Binary Universal Format for Representation (BUFR) of oceanographic data.

###### 2.2.2.1.4.10 Compression

General compression standards will be included in a later version of the JTA. See Section 2.2.2.1.4.4 for imagery compression standards.

##### 2.2.2.1.5 Graphic Services

These services support the creation and manipulation of graphics. They include device-independent, multidimensional graphic object definition, and the management of hierarchical database structures containing graphics data. The following standards are mandated for non-COTS graphics development:

- ISO 7942 as profiled by FIPS Pub 120-1 (change notice 1): 1991, Graphical Kernel System (GKS) - for 2-D graphics
- ISO 9592: 1989, as profiled by FIPS Pub 153, Programmers Hierarchical Interactive Graphics Systems (PHIGS) - for 3-D graphics
- ISO/IEC 9636: 1994, Information Technology-Computer Graphics-Interfacing (CGI) Techniques for Dialogue with Graphics Devices.

##### 2.2.2.1.6 Communications Services

These services support the distributed applications that require data access and applications interoperability in networked environments. The mandated standards are provided in Section 3.

##### 2.2.2.1.7 Operating System Services

These core services are necessary to operate and administer a computer platform and to support the operation of application software. They include kernel operations, shell, and utilities. The kernel controls access to information and the underlying hardware. These services shall be accessed by applications through either the standard Portable Operating System Interface (POSIX) or WIN32 APIs. Not all operating system services are required to be implemented, but those that are used shall comply with the standards listed below.

The following standards are mandated:

- ISO 9945-1: 1990, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 1: System Application Program Interface (API) [C language]*, (as profiled by FIPS PUB 151-2: 1994)
- ISO 9945-2: 1993, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 2: Shell and Utilities, (as profiled by FIPS PUB 189: 1994)
- IEEE 1003.2d: 1994, POSIX - Part 2: Shell and Utilities - Amendment: Batch Environment
- IEEE 1003.1b: 1993, POSIX - Part 1: System Application Program Interface (API) Amendment 1; Real Time Extension [C Language]*, (as profiled by FIPS Pub 151-2: 1993)
- IEEE 1003.1i: 1995, POSIX - Part 1: System Application Program Interface (API) Amendment: Technical Corrigenda to Real-time Extension [C Language]*
- IEEE 1003.1c: 1995, POSIX - Part 1: System Application Program Interface (API) Amendment 2: Threads Extension [C Language]*
- Win32 APIs, Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers Reference Manual, 1993, Microsoft Press.

Note: * - The reference to C Language is part of the formal title of these standards. It denotes the language used to define the standard.

#### 2.2.2.2 Application Platform Cross-Area Services

The TAFIM TRM defines four application platform cross-area services: Internationalization, Security, System Management, and Distributed Computing Services. See Figure 2-1.

##### 2.2.2.2.1 Internationalization Services

The internationalization services provides a set of services and interfaces that allow a user to define, select, and change between different culturally related application environments supported by the particular implementation. These services include character sets, data representation, cultural convention, and native language support.

In order to interchange text information between systems, it is fundamental that systems agree on the character representation of textual data. The following character set coding standards, which build upon the ASCII character set, are mandated for the interchange of 8-bit and 16-bit textual information respectively:

- ISO/IEC 8859-1: 1987, Information Processing - 8-Bit Single-Byte Coded Character Sets - Part 1: Latin Alphabet No. 1
- ISO/IEC 10646-1: 1993, Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane.

##### 2.2.2.2.2 Security Services

These services assist in protecting information and computer platform resources. They must often be combined with security procedures, which are beyond the scope of the information technology service areas, to fully meet security requirements. Security services include security policy, accountability, and assurance. [Note: Security Service standards have been consolidated in Section 6.)

##### 2.2.2.2.3 System Management Services

These services provide capabilities to manage an operating platform and its resources and users. System management services include configuration management, fault management, and performance management. Network Management mandated standards are provided in Section 3.2.1.1.1.5. There are no standards currently mandated for systems management.

##### 2.2.2.2.4 Distributed Computing Services

These services allow various tasks, operations, and information transfers to occur on multiple, physically- or logically-dispersed, computer platforms. These services include, but are not limited to, global time; data, file, and name services; thread services; and remote process services. There are two categories of Distributed Computing Services, Remote Procedure Computing and Distributed Object Computing.

###### 2.2.2.2.4.1 Remote Procedure Computing

The mandated standards for remote procedure computing are identified in the OSF Distributed Computing Environment (DCE) Version 1.1. The mandated standards are:

- OSF - DCE Remote Procedure Call (RPC), Version 1.1, 1994
- OSF - DCE Time Services, Version 1.1, 1994
- OSF - DCE Directory Services, Version 1.1, 1994.

###### 2.2.2.2.4.2 Distributed Object Computing

The mandated standards for distributed object computing are identified within the Object Management Group (OMG) Object Management Architecture (OMA) as described in:

- OMG - The Common Object Request Broker: Architecture and Specification, Version 2: July 1995 (also available as: X/Open Common Application Environment (CAE) Specification P431 - Common Object Request Broker Architecture & Specification, Version 2)
- OMG - CORBA services: Common Object Services Specification, March 1996 (also available as: X/Open CAE Specification P432 - Common Object Services, Volume 1 and X/Open CAE Specification P502 - Common Object Services, Volume 2)
- OMG - CORBA facilities: Common Object Facilities Architecture, November 1995.

## 2.3 EMERGING STANDARDS

The standards listed in this subsection are expected to be elevated to mandatory status when implementations of the standards mature.

### 2.3.1 Software Engineering Service

There are no emerging standards for software engineering services.

### 2.3.2 User Interface

Within User Interface Services space, the Common Open Software Environment (COSE) attempted to unify the existing GUI standards under a common framework. The result was the COSE CDE Version 1.0. This framework provides not only mechanisms for graphical display of common objects, but it also provides standard interprocess communication mechanisms and a set of commonly-used desktop tools (e.g., file manager and mail tool) that are relevant to many domains. There are a number of vendors who have received X/Open Brands for CDE 1.0. The next version of the CDE technology is being sponsored under the OSF Prestructured Technology (PST) business model. The effort has been designated CDENext.

### 2.3.3 Data Management

Within Data Management Services, standards for both RDBMS and Object-Oriented Database Management Systems (OODBMSs) will continue to evolve and mature. In the RDBMS domain, SQL3 is being developed by the ANSI X3H2 committee. In the OODBMS domain, the Object Database Management Group (ODMG) is evolving from the ODMG-93 specification to the ODMG-9x standard. SQL3 and ODMG-9x are being developed in parallel to ensure as much commonality as possible. Thus, an RDBMS that conforms to SQL3 will be able to access an OODBMS that conforms to ODMG-9x and vice versa. Both specifications are expected to be completed by mid-1997.

ISO 9075-3, 1995 Call Level Interface and DIS 9075-4, Database Language, Part 4: Persistent Stored Modules (SQL/PSM) are emerging standards for application programmer interface with DBMS servers. Open Data Base Connectivity (ODBC) 3.0 (once finalized) is expected to become the de-facto commercial standard for which vendors will build their products in the near future. However, since ODBC 3.0 is expected to support all of the ISO CLI standard, plus additional vendor extensions (not standard), it is an emerging standard for RDBMS procurement.

### 2.3.4 Data Interchange

Within Data Interchange Services, wavelet techniques are being reviewed for inclusion in the NITFS imaging standard. The ISO 13818-4, MPEG-2 is an interchange format used for full motion video and associated audio data for data rates of 1.5 Mbits/s - 6.0 Mbits/s.

HTML 3.2 is currently in work within the WWW Consortium as the successor to HTML 2.0. HTML 3.2 includes many of the highly desired features such as tables, found in non-standard forms in many vendors' products.

Geospatial standards are migrating from Military Standards to Interface Standards or to Standard Practices, both of which do not require waivers for use. MIL-STD-2405, Datums, Coordinates and Grids is being revised as an Interface Standard in FY96; MIL-STD-600001, Accurace, is slated for conversion to Standard Practices. If either standard is used prior to conversion they will require a waiver.

### 2.3.5 Operating Systems

Within Operating System Services, it is expected that the draft IEEE P1003.x POSIX standards will be adopted once they become final. The following POSIX drafts will be approved as standards soon:

P1003.1d Real-Time Extensions

P1003.1h Services for Reliable, Available, Serviceable Systems

P1003.1g Protocol Independent Interfaces

P1003.5b Ada Bindings for Real-Time

P1003.2l Real-Time Distributed Systems Communication

P1003.1j Advanced Real-Time Extensions

The X/Open Single UNIX Specification (SUS) (previously referred to as Specification 1170) is being updated to include POSIX real-time interfaces. Operating systems that conform to this specification and have received the UNIX brand from X/Open are on the market. For UNIX-based implementations, strong emphasis should be placed on acquiring systems that are SUS conformant over those that are not.

Go to Section 3.