DRAFT
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
FOR THE
DEFENSE INFORMATION INFRASTRUCTURE (DII)
COMMON OPERATING ENVIRONMENT (COE)
XML SERVICES (XS)
11 JUNE 1999
Version 2.0
Prepared by
DII COE AOG Data Access Services Technical Working Group (DATATWG)
Semi-Structured Data and Metadata Sub-panel (SSD-MD)
Jim Pipher & Jim Schoening, Co-Chairs
Prepared For
Defense Information System Agency (DISA)
DRAFT
TABLE OF CONTENTS
This Software Requirements Specification (SRS) establishes the functional, performance, and verification requirements for the XML Services (XS) functional area of the Defense Information Infrastructure (DII) Common Operating Environment (COE). The XS functional area includes Registration of terms (tags and structures), Design of XML schemas, Generation and Consumption of XML documents.
XML Services provide infrastructure services for mission and support applications using XML technology. These services isolate vendor-unique implementations of data access and provide applications a means of avoiding dependencies on physical access models. These services also provide data management functions for access to distributed (local and remote) database management systems as one of the solutions for interoperablity.
This document outlines the software capabilities required for the XS components for the DII COE. Section 2 lists the documents that are applicable to this specification. Section 3 provides a list of functional capabilities. Section 4 identifies the qualification requirements. Section 5 outlines the requirements and verification traceability matrix. Section 6 contains the applicable notes associated with the XS component.
SPECIFICATIONS:
Defense Information Infrastructure (DII), Shared Data Environment (SHADE), CAPSTONE DOCUMENT Version 1.0, 11 July 1996
ACCS-A1-100-006 System Specification for ATCCS, 22 March 1995
ATCCS-A1-302-001A Army Tactical Command and Control System Common ATCCS Support Software (CASS) Systems/Segment Specification
CDRL A142 AWIS Software Requirements Specification (ASRD), July 1992
CDRL ML03 AWIS Systems Management Manual (SMM), 31 Oct. 1994
AWIS Support Software Design Document, December 1994
D18664A Standard Theater Army Command and Control System (STACCS) System Design Document Version 1.1/As Built, 1 Oct. 93
AAN-SDA001A Standard Theater Army Command and Control System (STACCS) System Specification, Version 1.1/As Built, 1 Oct. 93
Standard Theater Army Command and Control System (STACCS) System Software Programmers Manual, Draft.
Global Command and Control System (GCCS) Integration Standard, Version 1.0, October 1994.
Global Command and Control System (GCCS) Common Operating Environment Baseline, DISA, 28 November1994.
User Interface Specifications for Global Command and Control System (GCCS), Version 1.0, October 1994.
Draft Architectural Design Document for the Global Command and Control System (GCCS) Common Operating Environment (COE), Version 3, 24 July, 1994.
STANDARDS:
MIL-STD-498 Military Standard - Software Development and Documentation,
DOD, Dec. 1994.
FIPS PUB 127-2 Database Language SQL - Federal Information Processing Standards Publication 127-2, 2 June, 1993.
MIL-STD-6040 Military Standard –
ISO/IEC 9070 Formal Public Identifier
Petrucci, Steve, "Cross-Platform Power Tools, Application Developers for the Macintosh, Windows, and Windows NT", Random House Electronic Publishing, 1993.
Donald Lewine,"POSIX Programmer's Guide", O'Reilly & Associates, Inc. 1991.
W3C Working Draft "Namespaces in XML"
The XS shall deliver inter-related components as shown in figure 3.2-1
Figure 3.2-1
pass request off to … (per explicit federation agreements)
The Registry shall provide standard APIs as specified in Appendix B.
The XS function shall provide standard APIs as specified in Appendix C.
Not applicable. Personnel requirements shall be determined by the developers of the system in which the XS module is embedded.
Not applicable. Training requirements shall be determined by the developers of the system in which the XS module is embedded.
The XS developer is responsible for software maintenance, software support, and software updates. The DISA Configuration Manager (CM) is responsible for distribution of the XS product to system developers.
None.
The XS software shall be delivered in accordance with DII COE guidelines.
The following table depicts the mapping of the requirements in Section 3 to their corresponding precedence and criticality code and to other related requirements within the XS SRS. The precedence and criticality codes are the following:
|
Requirement/ Paragraph Number |
Requirement Description |
Prec |
Related Requirement Within XS SRS |
|
TBD |
|||
COE Software will be qualified through formal validation tests of the SRS level requirements. The Qualification Methods applied to the software shall include test, demonstration, analysis, and inspection (T, D, A, I).
A qualification method that is carried out by operation of the item/component/I/F (or some part of the computer S/W configuration item, etc.) and that relies on the collection and subsequent examination of data.
A qualification method that is carried out by operation of the item/component/I/F (or some part of the computer S/W configuration item, etc.), and that relies on observable functional operation not requiring the use of elaborate instrumentation or special test equipment.
A qualification method that is carried out by the processing of accumulated data. An example of accumulated data is the compilation of data obtained from other qualification methods. Examples of the processing of accumulated data are interpretations or extrapolations made from the data.
A qualification method that is carried out by visual examination, physical manipulation, or measurement to verify that the requirements have been satisfied.
Provided under separate document.
ACCS Army Command and Control Systems
GCCS-AAGCCS Army Global Command and Control System- Army
ANSI American National Standards Institute
API Application Programming Interface
ASCII American Standard Code Information Interchange
ASCII RTF American Standard Code Information Interchange Rich Text Format
ASRD AWIS Software Requirements Specification Document
ATCCS Army Tactical Command and Control Systems
AWIS Army WWMCCS Information System
CASS Common ACCS Support Software
CLI Client Library Interface
CM Configuration Manager
COE Common Operating Environment
COTS Commercial Off-The-Shelf
X-DA Data Access
DAC Discretionary Access Control
XS Data Access Service
DBIF Database Interface
DBMS Database Management System
DBs Databases
DATATWG Data Access Services Technical Working Group
DCE Distributing Computing Environment
DDL Data Definition Language
DDS Data Distribution System
DES Data Encryption Standard
DID Data Item Description
DII Defense Information Infrastructure
DISA Defense Information Systems Agency
DML Data Manipulation Language
DoD Department of Defense
DTG Date-Time-Group
FIPS PUB Federal Information Processing Standards Publication
FMWG File Management Working Group
GCCS Global Command and Control Systems
GOTS Government Off-The-Shelf
GUI Graphical User Interface
HP Hewlett-Packard
IAW in accordance with
ID Identification
I/F Interface
IF Intell Fusion
I/O Input/Output
JMCIS Joint Maritime Command Information System
JOBES Joint Operation Planning and Execution System
MAC Mandatory Access Control
Mbs Megabytes
MCG&I Mapping, Charting, Geodesy and Imagery
MIL-STD Military Standard
MSB Most Significant Bit
OS Operating System
PM Project Manager
POSIX Portable Operating System Interface for Computing Environments
RAID Redundant Array of Inexpensive Disks
RDA Remote Database Access
RDBMS Relational Database Management System
RISC Reduced Instruction Set Computer
RTF Rich Text Format
SECTWG Security Services Technical Working Group
SMM Systems Management Manual
SQL Structured Query Language
SRI Standing Request for Information
SRS Software Requirements Specification
SSDD Support Software Design Document
STACCS Standard Theater Army Command And Control System
S/W Software
TBD To Be Determined
WWMCCS World-Wide Military Command and Control System
Automatically: Indicates processing initiated during execution of other processes, but dependent on information and/or parameters to be generated or supplied to these other processes. The information / parameters may be data dependent, or application dependent, or dependent on a manual process/human intervention. It will include controls qualifying the processing involved.
Business Rule: A narrative description of policies, procedures, or principles within an organization. Business rules can be divided in to four categories: definitions, facts, constraints, and derivations.
Definitions are business rules that define entities and attributes.
Facts are either links (relationships) between entities or associations
between an entity and attributes
Constraints are conditions about the data that must always be true. They are the integrity rules that protect the data in the eventual database.
Derivations are business rules that materialize a new piece of information (often attribute values) from other pieces of information. For example, a mathematical derivation might specify that you can obtain a person's age by subtracting his or her birth date from the current date.
Commit/Rollback: An individual transaction is processed (commit) or discarded (rollback) by the proponent maintainer of the data items involved.
Discretionary Access Controls (DAC): A means of restricting access to objects based on the identity of subjects or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission on to any other subject.
Dynamically Generated Processing: Indicates processing initiated during execution of other processes, but dependent upon information and/or parameters to be generated or supplied to these other processes. The information/parameters may be data dependent, or application dependent, or dependent on a manual process/human intervention. It will include controls qualifying the processing involved.
Location Transparency: occurs when the physical location of data is transparent to the applications and users of the database system. For example, a view that joins table data from several databases provides location transparency because the user of the view does not need to know where the data originates from.
Mandatory Access Control (MAC): mediates access to an object based on the clearance level of the subject (user) and the sensitivity label of the object. (These controls are always enforced above any discretionary control implemented by users).
Mirrored Databases: Replication and maintenance of a database on a transaction basis for the purpose of rapid error or failure recovery as supported by the resident COTS RDBMS own system utilities and operating system.
Object: A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are records, blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, and network nodes.
Proponent Scheme: Describes the sites at which databases are replicated and also who owns and has update authority with respect to the data at each site. It refers to proponency at the source and record level.
Redundant Array of Inexpensive Disks (RAID): A RAID system appears as one very large, reliable disk to the CPU. The main reason for using RAID storage is its reliability. RAID has the same advantages as shadowing and striping at a lower cost. There are several types/levels of RAID implementations, including: RAID 0 (known as disk striping), RAID 1 (known as disk shadowing), RAID 3 (in which data is distributed in small increments across all data disks and adds a parity value to a separate disk for recovery if any disk fails, RAID 4 (in which data is distributed in large chunks across all data disks and also has a single parity disk. RAID 4 intended to overcome performance penalties of RAID 3 for small transfers. RAID 5 (in which parity over RAID 3 or RAID 4 implementations), and RAID 6 ( in which two parity disks in addition to data disks are used in an attempt to further improve performance). In a RAID 5 implementation, the data is stored as are check sums and other information about the contents of each disk in the array. If one disk is lost, the others can use the check sums and other stored information to recreate the lost data. Storage system vendors may provide additional enhancements to RAID level implementations to improve performance and reliability.
Remote Data Access (RDA): is an ISO (9579) application layer interoperability standard (protocol and formats) to support access by an application to a (remote) DBMSs over an OSI network. The goal of RDA is to allow interoperability between applications (clients) and databases (servers) of different manufacturers so that an application is able to read and update data in remote databases via well defined standards. RDA defines a set of client and server standards and a mapping of SQL commands to these services. RDA also defines an interface to ISO (transaction processing) two phase commit TP services in the case where updates to multiple remote databases need to be coordinated. RDA does not yet define interoperability between server databases (i.e. it is not yet a standard for distributed database management).
Replication Scheme: Information that precisely identifies DBs, or partitions of DBs, to be copied and/or distributed, replication schedules, and master/remote sites that are to receive the copies.
Spatial DBMS: Geographic information system that organizes and maintains spatial data (i.e. data with graphical attributes) in terms of type, scale, location(s), extent, topology and geometry. Supports queries of spatial data where the selection criteria are defined by spatial attributes.
SRI: A Standing Request For Information (SRI) is a capability in which CASS monitors for the occurrence of conditions established by an application program, and notifies the calling or establishing application program when the conditions are satisfied. An SRI may be one of three types: timer-based, data-based, or message-based.
Subject: An active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. Technically, a process/domain pair.
Transaction Journalling: Individual messages or database transactions are stored in a journal file, which may be a linear log file or a circular file.
The metadata and procedures are described for the current Information Resource Submittal Package .
Metadata and Related Information
An XML tag may be described as any object and is easily created by anyone using a text editor. Although XML is a relatively new technology, many developers are already using XML in operational COE systems and have already created tags and specifications, many of which may be inconsistent with tags used in other systems. So far, the burgeoning sets of XML tags have created redundancy and irrelevancy, and they lack validity.
XML Registry.
To ensure interoperability, this registry provides a baseline set of tags developed through coordination and approval among the Community. The Registry allows a user to browse, search, and retrieve data that satisfy your requirements. The Registry has a substring search capability so that the user may easily find information resources that meet the criteria. The user may specify whether to search for the term within the name of the information resource or the definition or both.
Developer's Role.
Developers are urged to review the baseline tags, adopt them where possible, and subscribe to future notifications about the tags. If, after reviewing the tags in the Registry, you cannot reuse an existing specification (a.k.a. Document Type Definition (DTD)) or existing tags, you may submit your proposed tag to a Community of Interest (COI) and provide amplifying information for all to understand the semantics for its proper use.
COE Chief Engineer's Role.
The COE Chief Engineer will approve a single Point of Contact (POC) for a COI to manage the tags within that COI. The COE Chief Engineer will reserve ultimate authority to mediate any unresolved disputes within all COIs.
The COE Data Engineering Team's Role.
Tags and semantics will be analyzed to identify opportunities to consolidate tags towards a single or a minimal number of representations. A "market forces" model can also guide COE Data Engineering in identifying the weak candidates from the strong.
The Community of Interest's POC's Role.
(The information in the following section is current as of 17 May, 1999. Please consult the Registry for the most authoritative list of information resources types.) The POC responsibilities will include the transitioning of information resources from one status to another. Table 1 lists the valid types of information resources. The status levels are developmental, candidate, approved, rejected, and retired.
Table 1 Information Resource Types
| Information Resource |
Description |
|
XML_Element |
tag, either complex or terminal node |
|
XML_Attribute |
characteristic of an element, may be constrained by enumeration |
|
Model |
a representation using a formalism such as IDEF1x or Object Modeling |
|
XML_Spec |
a DTD or DCD; the schema for an XML document |
|
Domain |
the valid values for an element or attribute; expressed as a valid SQL expression or by reference to a separately available set (e.g., XML doc of current CTRY values) |
|
XML_Namespace |
the reference for uniqueness within the Registry |
|
Catalog |
a Registry which conforms to some explicit rules of engagement |
|
Document |
any other amplifying information that is available (e.g., readme.txt) |
|
Table 2 - Information Resource Association Types |
|
| Forward term |
Reverse term |
|
uses |
used_by |
|
describes |
described_by |
|
is_XML_spec_for |
defined_by_XML_spec |
|
is_newer_version_of |
is_older_version_of |
|
is_constrained_by_domain |
is_domain_for |
|
belongs_to_namespace |
is_namespace_for |
|
element_may_be_qualified_by_attribute |
attribute_may_qualify_element |
|
is_model_for |
is_modeled_by |
Procedures
For Developers may submit and use information resources within the Registry constitutes guidance in the generation and use of XML as an authoritative source for approved XML data and metadata components.
Zip and attach submission package to e-mail message to: ____________________
Rules and Convensions.
Establishing a new Information Resource. Follow these conventions for creating new information resources for the Registry
Include descriptive definitions AND synonyms for the Information Resource Definition.
Initially, the Registry will not have keyword, thesaurus, or ontology support but it will have a substring search for a number of fields, including definition. Therefore, we urge submitters to include enough expressive terms so that COE developers would easily find the term they might consider "natural" in the definition and find the desirable tag for expressing that concept. Example: If the registered tag is ORG_ID, the description that includes references
The External Interfaces for the XS SRS are defined as interfaces to non-COE components. Detailed information (as specified in paragraph 3.3 of the Data Item Description DI-IPSC-81433) defining these interfaces will be specified during the design phase of the COE XS architecture. At this time such detailed information is unavailable.
The Internal Interfaces for the XS SRS are defined as interfaces to COE components. Detailed information (as specified in paragraph 3.4 of the Data Item Description DI-IPSC-81433) defining these interfaces will be specified during the design phase of the COE XS architecture. At this time such detailed information is unavailable.
The COE components identified to-date are listed below.
It incorporates other interfaces to:
It incorporates other interfaces to:
It incorporates other interfaces to:
It incorporates other interfaces to:
It incorporates other interfaces to:
It incorporates other interfaces to:
The Interfaces to Commercial Products for the XS SRS are identified below. Detailed information (as specified in paragraph 3.3 of the Data Item Description DI-IPSC-81433) defining these interfaces will be specified during the design phase of the COE XS architecture. At this time such detailed information is unavailable.
The three commercial products or environments identified for the COE are the following Relational Database engines: