FOREWORD This Manual is published by direction of the Deputy Under Secretary of Defense (Logistics) under the authority of the Department of Defense Directive 4140.1, "Materiel Management Policy." The purpose of this Manual is to provide uniform procedures for operation of the DoD Logistics Data Element Standardization and Management Program (LOGDESMAP) as prescribed by DoD Directive 8320.1, "Department of Defense Data Administration," September 26, 1991, and its implementing procedures, DoD 8320-1-M-1, "Department of Defense Data Element Standardization Procedures," January 1993. This Manual also provides guidance and procedures for the standardization and management of data elements used in DoD-wide and joint Service/Agency logistics systems, authoritative issuances and procedures. The provisions of this Manual are effective when published. Department of Defense activities and activities of external organizations participating in the DoD LOGDESMAP who require additional copies should submit requests through their respective office(s) responsible for issuing publications. Non-participating activities may obtain copies of this Manual from: ATTN: DASC-VC ROOM 1560 DLA ADMINISTRATIVE SUPPORT CENTER 8725 JOHN J. KINGMAN ROAD FORT BELVOIR, VA 22060-6221 703-767-1272 DSN 427-1272 703-767-5100 DSN 427-5100 TABLE OF CONTENTS Page FOREWORD2 TABLE OF CONTENTS3 REFERENCES6 DEFINITIONS7 ABBREVIATIONS AND/OR ACRONYMS11 CHAPTER 1 - INTRODUCTION13 C1.1. AUTHORITY13 C1.2. PURPOSE13 C1.3. SCOPE AND APPLICABILITIY13 C1.4. OBJECTIVES14 C1.5. STRATEGY14 C1.6. POLICIES15 C1.7. RESPONSIBILITIES15 C1.8. EFFECTIVE DATE15 CHAPTER 2 - DoD DATA ADMINISTRATION PROGRAM16 C2.1. DATA ELEMENT CONCEPTS16 C2.2. DATA ELEMENT16 C2.3. GENERIC ELEMENT18 C2.4. DOMAIN19 C2.5. METADATA20 C2.6. DATA ELEMENTS STANDARDIZATION PHASES20 CHAPTER 3 - DATA ELEMENT DESIGN, DEFINITION, AND NAMING22 C3.1. PURPOSE22 C3.2. DATA ELEMENT DESIGN22 C3.3. DATA ELEMENT DEFINITION23 C3.4. DATA ELEMENT NAMING24 TABLE OF CONTENTS, cont. Page CHAPTER 4 - LOGISTICS DATA ELEMENT DEVELOPMENT PROCEDURES27 C4.1. INTRODUCTION27 C4.2. PURPOSE27 C4.3. ASSEMBLE SOURCE DOCUMENTATION28 C4.4. IDENTIFY PRIME WORD NAME (MANDATORY) WITH MODIFIER NAME(S) (OPTIONAL)29 C4.5. DEVELOP DEFINITION OF PRIME WORD AND MODIFIERS30 C4.6. DEVELOP GENERIC ELEMENT NAME (MANDATORY)30 C4.7. DEVELOP GENERIC ELEMENT DEFINITION (MANDATORY)31 C4.8. IDENTIFY GENERIC ELEMENT NAME (MANDATORY) WITH PROPERTY ODIFIER (OPTIONAL)31 C4.9. DEVELOP DEFINITION OF GENERIC ELEMENT AND MODIFIER(S)32 C4.10. DEVELOP DATA ELEMENT NAME (MANDATORY)32 C4.11. DEVELOP DATA ELEMENT DEFINITION (MANDATORY)32 C4.12. RESEARCH EXISTING ELEMENTS33 C4.13. IDENTIFY GENERIC ELEMENT DOMAIN (MANDATORY)34 C4.14. RECORD REMAINING GENERIC ELEMENT ATTRIBUTES35 C4.15. IDENTIFY DATA ELEMENT DOMAIN (MANDATORY)35 C4.16. RECORD REMAINING DATA ELEMENT ATTRIBUTES35 C4.17. SUBMIT PROPOSED ELEMENET(S) FOR APPROVAL36 CHAPTER 5 - STANDARDIZATION APPROVAL PROCESS37 C5.1. PURPOSE37 C5.2. COORDINATION PROCEDURES37 C5.3. PRELIMINARY REVIEW38 C5.4. FORMAL REVIEW40 CHAPTER 6 - DATA ELEMENT MAINTENANCE PROCEDURES43 C6.1. PURPOSE43 C6.2. REGISTERING DATA ELEMENT APPLICATIONS43 C6.3. MODIFYING EXISTING STANDARD DATA ELEMENTS45 C6.4. ARCHIVING STANDARD DATA AND GENERIC ELEMENTS45 C6.5. REINSTATING ARCHIVED STANDARD DATA AND GENERIC ELEMENTS47 TABLE OF CONTENTS, cont. Page CHAPTER 7 - ANSI ASC X12 TRANSACTION SETS/DATA SEGMENTS/DATA ELEMENTS48 C7.1. PURPOSE/APPLICABILITY48 C7.2. DATA ELEMENT48 C7.3. COMPOSITE DATA STRUCTURE53 C7.4. CODE SOURCES53 C7.5. INFORMATION SYSTEM54 CHAPTER 8 - DOCUMENT IDENTIFIER (DI) CODE ASSIGNMENT55 C8.1. AUTHORITY/PURPOSE55 C8.2. SCOPE55 C8.3. OBJECTIVES56 C8.4. DOCUMENT IDENTIFIER CODE SERIES RESERVATIONS56 C8.5. GUIDELINE CRITERIA56 C8.6. PROCESSING OF REQUESTS FOR THE RESERVATION AND ALLICATION OF DI CODE SERIES57 CHAPTER 9 - DoD LOGDRMS58 C9.1. CONFIGURATION58 C9.2. GENERAL58 C9.3. ACCESSING THE SYSTEM USING A PERSONAL COMPUTER AND MODEM59 C9.4. ACCESSING THE SYSTEM USING HARDWARE OR AN OPEN SYSTEM NETWORK (SUCH AS DDN)59 C9.5. QUERY PROCEDURE60 C9.6. OPTION 1 ANSI ASC X 12 QUERY PROCEDURE AND MENU SELECTION60 C9.7. OPTION 2 DLMS QUERY PROCEDURE AND MENU SELECTION61 C9.8. OPTION 3 UN/EDIFACT MESSAGES62 C9.9. TERMINATION OF SESSION62 APPENDIX 1 - CLASS WORD NAME DEFINITIONS63 APPENDIX 2 - GENERIC AND DATA ELEMENT ATTRIBUTE DESCRIPTIONS66 ATTACHMENT 1 TO APPENDIX 2 - INDEX OF ATTRIBUTE DESCRIPTIONS87 APPENDIX 3 - DATA STANDARDIZATION DETAILED PROCEDURES90 REFERENCES (a) DoD 4000.25-M, "Defense Logistics Management System (DLMS) Standards and Procedures," February 14, 1996 (b) DoD 4000.25-1-M, "Military Standard Requisitioning and Issue Procedures (MILSTRIP), Changes 1-9," May 1987 (c) DoD 4000.25-1-S1, "MILSTRIP Routing Identifier and Distribution Codes," August 1994 (d) DoD 4000.25-1-S2, "Defense Program for Redistribution of Assets (DEPRA) Procedures, Changes 1-3," August 1987 (e) DoD 4000.25-2-M, "Military Standard Transaction Reporting and Accounting Procedures (MILSTRAP), Changes 1-4," May 1987 (f) DoD 4000.25-3-M, "Military Supply and Transportation Evaluation Procedures (MILSTEP)," September 1987 (g) DoD 4000.25-5-M, "Military Standard Contract Administration Procedures (MILSCAP), Changes 1-2," March 1993 (h) DoD 4000.25-6-M, "Department of Defense Activity Address Directory (DoDAAD, Part I. Activity-Address Code Sequence, Part II. ZIP Code Sequence, Part III. Civil Agency Addresses," April 1995 (i) DoD 4000.25-7-M, "Military Standard Billing System (MILSBILLS), Changes 1- 4," January 1985 (j) DoD 4000.25-8-M, "Military Assistance Program Address Directory (MAPAD) System, Changes 1-13," March 1993 (k) DoD 4000.25-13-M, "Department of Defense Logistics Data Element Standardization and Management Program (DoD LOGDESMAP) Procedures," January 1984 (l) DoD 4140.1-R, "DoD Materiel Management Regulation," January 1993 (m) DoD Directive 8000.1, "Defense Information Management (IM) Program," October 27, 1992 (n) DoD Directive 5200.28, "Security Requirements for Automated Information Systems (AISs)," March 21, 1988 (o) DoD Directive 8320.1, "DoD Data Administration," September 26, 1991 (p) DDRS End User Manual, September 1994 (q) DoD Directive 4140.1, "Materiel Management Policy," January 4, 1993 (r) DoD 8320.1-M-1, "DoD Data Element Standardization Procedures," January 1993 (s) MIL-STD-2167-A (t) DoD Directive 7935.1 DL1. DEFINITIONS DL1.1.1. Application Data Element. A data element used in an automated information system. (An application data element may, or may not, be a standard data element.) DL1.1.2. Attribute. A property or characteristic of one or more entities; for example, COLOR, WEIGHT, SEX. Also, a property inherent in an entity or associated with that entity for database purposes. DL1.1.3. Class Word. A word in the name of a data element describing the category to which the data element belongs; e.g., "date," "name," "code." The word establishes the general structure and domain of a standard data element. DL1.1.4. Data. A representation of facts, concepts, or instructions in a formalized manner suitable for communications, interpretation, or processing by humans or by automatic means. DL1.1.5. Data Administration (DAdm). That function of the organization that oversees the management of data across all functions of the organization, and is responsible for central information planning and control. DL1.1.6. Data Administrator (DAd). A person or group that ensure the utility of data used within an organization by defining data policies and standards, planning for the efficient use of data, coordinating data structures among organizational components, performing logical database design, and defining data security procedures. DL1.1.7. Data Attribute. A characteristic of a unit of data such as length, value, or method of representation. DL1.1.8. Data Dictionary. A specialized type of database containing metadata that is managed by a data dictionary system; a repository of information describing the characteristics of data used to design, monitor, document, protect, and control data in information systems and databases; and application of data dictionary system. DL1.1.9. Data Element. A named identifier of each of the entities and their attributes that are represented in a database. DL1.1.10. Data Element Standardization. The process of documenting, reviewing and approving unique names, definitions, characteristics and representation of data elements according to established procedures and conventions. DL1.1.11. Data Entity. An object of interest to the enterprise, usually tracked by an automated system. DL1.1.12. Data Model. In a database, the user's logical view of the data in contrast to the physically stored data, or storage structure. A description of the organization of data in a manner that reflects the information structure of an enterprise. DL1.1.12.1. Logical Data Model. A model of the data stores and flows of the organization derived from the conceptual business model. DL1.1.12.2. Physical Data Model. A representation of the technologically independent requirements in a physical environment of hardware, software, and network configurations representing them in the constraints of an existing physical environment. DL1.1.13. Data Steward. The person or group that manages the development, approval, and use of data within a specified functional area, ensuring that it can be used to satisfy data requirements throughout the organization. DL1.1.14. Data Structure. The logical relationships which exist among units of data and the descriptive features defined for those relationships and data units; an instance or occurrence of a data model. DL1.1.15. Dictionary. See Data Dictionary. DL1.1.16. Domain. The set of permissible data values from which actual values are taken for a particular attribute or specific data element. In a relational database, all of the permissible tuples for a given relation. DL1.1.16.1. General Domain. The permissible data values allowed in representations of a data element defined in terms of the character set that can be used; e.g., A-Z, 0-9, etc. DL1.1.16.2 Specific Domain. An enumerated set of values allowed in data representations of a data element; e.g., Friday, Saturday, Sunday. DL1.1.17. Entity. See Data Entity. DL1.1.18. Generic Element. A generic element is the part of a data element that establishes a structure and limits the allowable set of values of a data element. A generic element has no functional or application context other than to define a general class of data and ensure consistency in structure and domain. DL1.1.19. Information. Any communication or reception of knowledge such as facts, data, or opinions, including numerical, graphic, or narrative forms, whether oral or maintained in any medium, including computerized databases, paper, microforms, or magnetic tape. DL1.1.20. Information System. The organized collection, processing, maintenance, transmission, and dissemination of information in accordance with defined procedures, whether automated or manual. DL1.1.21. Metadata. Information describing the characteristics of data; data or information about data; descriptive information about an organization's data, data activities, systems, and holdings. DL1.1.22. Migration Data. Data from or within a migration system. See also Migration System. DL1.1.23. Migration System. An existing automated information system, or a planned and approved automated information system, that has been officially designated to support standard processes for a functional activity applicable DoD-wide or Component-wide. DL1.1.24. Modifier. A word that helps define and render a name unique within the database, which is not the prime or class word. DL1.1.25. Nonstandard Data Element Any data element that exists in a system or application program and does not conform to the conventions, procedures, or guidelines established by the organization. DL1.1.26. Prime Word A word included in the name of a data entity that represents the logical data grouping (in the logical data model) to which it belongs. DL1.1.27. Property Modifier. A word (adjective) that may occur in a data element name between the prime word and the class word modifiers. Property modifiers result directly from the attributes of a data model entity and further refine the prime word, or the class word, but do not dictate the structure of the data element. Normally, property modifiers are related to the generic element. DL1.1.28. Qualitative Data. A data value that is a non-numeric description of a person, place, thing, event, activity, or concept. DL1.1.29. Quantitative Data. Numerical expressions that use Arabic numbers, upon which mathematical operations can be performed. DL1.1.30. Standard Data Element. A data element that has been submitted formally for standardization in accordance with the organization's data element standardization procedures. AL1. ABBREVIATIONS AND/OR ACRONYMS AL1.1. ADUSD(L) (LBS&TD) Assistant Deputy Under Secretary of Defense for Logistics, Business Systems and Technology Development AL1.2. AIS Automated Information System AL1.3. ANSI American National Standards Institute AL1.4. ASC X12 Accredited Standards Committee X12 AL1.5. ASCII American Standard Code for Information Interchange AL1.6. CCB Configuration Control Board AL1.7. CDAd Component Data Administrator AL1.8. DAAS Defense Automatic Addressing System AL1.9. DAASC Defense Automatic Addressing System Center AL1.10. DAd Data Administrator AL1.11. DBMS Database Management System AL1.12. DDI Director, Defense Information AL1.13. DDN Defense Data Network AL1.14. DDRS Defense Data Repository System AL1.15. DED/D Data Element Dictionary/Directory AL1.16. DEPRA Defense Program for Redistribution of Assets AL1.17. DI Document Identifier AL1.18. DISA Defense Information Systems Agency AL1.19. DLMS Defense Logistics Management System AL1.20. DLMSO Defense Logistics Management Standards Office AL1.21. DLSS Defense Logistics Standard Systems AL1.22. DoD Department of Defense AL1.23. DoDAAD Department of Defense Activity Address Directory AL1.24. DSN Defense Switched Network AL1.25. DTIC Defense Technical Information Center AL1.26. DUSD(L) Deputy Under Secretary of Defense of Logistics AL1.27. EC Electronic Commerce AL1.28. EDI Electronic Data Interchange AL1.29. FDAd Functional Data Administrator AL1.30. FIPS Federal Information Processing Standards AL1.31. ID Identifier AL1.32. IRM Information Resource Management AL1.33. LDM Logistics Data Manager AL1.34. LMARS Logistics Metric Analysis Reporting System AL1.35. LOGDESMAP Logistics Data Element Standardization and Management Program AL1.36. LOGDRMS Logistics Data Resource Management System AL1.37. MAPAD Military Assistance Program Address Directory AL1.38. MILSBILLS Military Standard Billing System AL1.39. MILSCAP Military Standard Contract Administration Procedures AL1.40. MILSPETS Military Standard Petroleum System AL1.41. MILSTEP Military Supply and Transportation Evaluation Procedures AL1.42. MILSTAMP Military Standard Transportation and Movement Procedures AL1.43. MILSTRAP Military Standard Transaction Reporting and Accounting Procedures AL1.44. MILSTRIP Military Standard Requisitioning and Issue Procedures AL1.45. MODELS Modernization of Defense Logistics Standard Systems AL1.46. NBS National Bureau of Standards AL1.47. NIST National Institute of Science and Technology (Formally National Bureau of Standards) AL1.48. NTIS National Technical Information Service AL1.49. OSD Office of the Secretary of Defense AL1.50. PRC Process Review Committee AL1.51. S/A Service(s)/Agency(ies) C1. CHAPTER 1 INTRODUCTION C1.1. AUTHORITY This Manual is authorized by DoD Directive 4140.1 (reference (q)) and DoD 4140.1-R, "DoD Materiel Management Regulation," January 1993 (reference (l)). C1.2. PURPOSE C1.2.1. This Manual promulgates the procedures for data administration required to support the policies of the DoD Data Administration Program established by DoD Directive 8320.1, September 26, 1991 (reference (o)), and provides guidance and uniform procedures for DoD data element standardization under guidelines provided in DoD 8320.1-M-1, January 1993 (reference (r)). C1.2.2. This Manual also provides procedures for electronic interchange of data across the Military Services, Defense Agencies, other Federal Agencies, foreign national governments, international government organizations, and with non-government participants utilizing American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 procedures. C1.3. SCOPE AND APPLICABILITY C1.3.1. The provisions of this Manual apply to all DoD Component organizations involved in the development, design, or modification of DoD-wide and joint Military Service/DoD Agency automated logistics systems and authoritative issuances that prescribe the collection, reporting, or interchange of logistics data. C1.3.2. For the purposes of this Manual, logistics encompasses responsibilities assigned to the Deputy Under Secretary of Defense for Logistics (DUSD(L)). Any exemptions to the policies expressed herein must be requested from and granted by the Assistant Deputy Under Secretary of Defense for Logistics, Business Systems and Technology Development ADUSD(L)(LBS&TD)). C1.4. OBJECTIVES C1.4.1. Support DoD logistics operations and decision-making with data that meets the needs of the DoD Logistics community in terms of availability, accuracy, timeliness, and quality. C1.4.2. Structure the supporting information system, the DoD Logistics Data Resource Management System (LOGDRMS) in ways that encourage horizontal, as well as vertical, sharing of data in the Department of Defense, with Government Agencies, private sector organizations and allied nations, consistent with national security and privacy requirements. C1.4.3. Improve business methods, measure improvements and evolve to more efficient, effective and economic data and system environment architectures. C1.5. STRATEGY Pursuant to the stated objectives, this Manual describes an integrated DoD Logistics community-wide data administration structure and procedures for managing data as a DoD resource. It includes the criteria and rules for standardization of data elements and their attributes throughout the Department of Defense. It is the intent of DoD logistics data administration, through this Manual, to: C1.5.1. Develop logistics data standards to satisfy DoD Component mission needs and operational capabilities requiring the collection, storage and exchange of data. C1.5.2. Develop an awareness of the value of data and of the need for uniform description and representation of data. Accordingly, information derived from this can be used in effective decision-making that supports the concept of decision support and executive information systems. C1.5.3. Encourage the use of DoD logistics data standards to improve program effectiveness both to the program and to the DoD Logistics community as a whole, through self-enforcement and cooperation among program and data administrators. C1.5.4. Promote interoperability and data sharing among DoD logistics systems while ensuring that data security and integrity are maintained C1.5.5. Specify appropriate methods and techniques for the management and control of data throughout the DoD Logistics community. C1.5.6. Develop common data requirements and formats for elimination of redundancies. C1.5.7. Interface the data elements developed for the DoD Data Element Standardization Program with ANSI ASC X12 standards, for electronic data interchange (EDI) thereby providing a common basis for communicating shared business information. C1.6. POLICIES C.1.6.1. DoD standard or DoD logistics standard data elements will be used in the development or redesign of DoD-wide and joint Service/Agency systems and issuances that fall within the scope of the DoD Logistics Data Element Standardization and Management Program (LOGDESMAP). C.1.6.2. The use of prescribed data item codes will be rigidly applied for machine processing and electronic data transmission. C.1.6.3. All data elements employed in systems and issuances within the scope of the DoD LOGDESMAP that have not been standardized in accordance with DoD 8320.1-M-1, "DoD Data Element Standardization Procedures" (reference (r)), will be standardized as DoD logistics standard data elements under the procedures prescribed in this Manual. C.1.6.4. A DoD Logistics Data Element Dictionary/Directory is available for on-line access by all participating DoD Components. See Chapter 9 for instructions. C1.7. RESPONSIBILITIES Specific responsibilities of each DoD Component are covered in the individual parts of this Manual under specific procedures or guidance. C1.8. EFFECTIVE DATE This Manual is effective upon formal publication. C2. CHAPTER 2 DoD DATA ADMINISTRATION PROGRAM C2.1. DATA ELEMENT CONCEPTS The concepts discussed in this chapter are fundamental to the development, identification, and definition of standard generic elements and standard data elements. This information provides a basis for understanding the development, approval, and maintenance procedures for generic elements and data elements. C2.2. DATA ELEMENT C2.2.1. A data element is a basic unit of information having a name, meaning, and subcategories (data items) of distinct units and values. Through its name and definition a data element must convey a single, informational concept. C2.2.2. Data elements are derived from data entities and their attributes identified in data models. Each data element is the physical representation of a data model entity attribute. C2.2.3. A data element name consists of a prime word, a class word, and modifiers. C2.2.4. Any data element that has been identified as a functional data requirement in a validated, approved Component or functional data model, which can be related to the DoD data model, and is used by more than one application or information system will be standardized. C2.2.5. Any data element that has been prescribed by information system computer program specifications to support internal system processing requirements only, will not be standardized (e.g., logic flow control, counters, subscripts, "flags"). C2.2.6. All standard data elements must be documented in accordance with the DoD standardization procedures and naming conventions established in Chapter 3, below. There are five possible components of a data element: C2.2.6.1. Prime Word C2.2.6.1.1. A prime word is the noun designation given to an entity identified in a data model. For example, a company may need to maintain information about customers, so an entity "Customer" could exist. The prime word for this entity would be called "Customer." The prime word identifies the object to which the data element refers. C2.2.6.1.2. Prime words are centrally controlled and maintained by the DoD Data Administrator (DAd). Proposals for new prime words must be based on an explanation of the DoD Data Model and submitted through the appropriate Component or Functional Data Administrator to the DoD DAd for approval. Words used as prime words in some data element names may be used as modifiers in other data element names. C2.2.6.2. Prime Word Modifier. Prime word modifiers are adjectives that further refine and categorize the prime word. They designate the name of a data subentity in the data model and distinguish it from other subentities of the same data entity. They are needed to distinguish that data subcategory from other subcategories of data represented by the data entity. For example, a company may be interested in information about two distinct groups of customers, "Retail Customers" and "Wholesale Customers." The prime word modifiers "Retail" and "Wholesale" are used to distinguish between these two types of customers C2.2.6.3. Class Word C2.2.6.3.1. A class word is a noun that prescribes a definition for a general category of data. A class word designates the category of data into which a data element fits. Examples of class words are: "Code," "Name," and "Quantity." C2.2.6.3.2. Class words are centrally controlled and maintained by the DoD DAd. DoD class words are listed in Appendix 1, below, together with Figure A-1 to assist in class words selection. Proposals for new class words must be submitted through the appropriate Component or Functional Data Administrator to the DoD DAd for approval. Class words are restricted and cannot be used as prime words or modifiers in a data element name. C2.2.6.4. Class Word Modifiers C2.2.6.4.1. A class word modifier is a word (adjective) that is used to further refine or describe a class word. When used, a modifier must distinguish one data element from another and normally will narrow the range of the allowable values established by a class word. C2.2.6.4.2. Example: Month Name. Here, "Month" is modifying the class word "Name" and restricts the possible range of values from all possible names of anything to names of months. C2.2.6.5. Property Modifiers C2.2.6.5.1. The second group of modifiers that may occur in a data element name are between the prime word and the class word modifiers. They are property modifiers. They result directly from the attributes of a data model entity and further refine the prime word, or the class word, but do not dictate the structure (maximum size or data type; e.g., real, integer, character) of the data element. Normally, they are modifiers to the generic element, discussed in section C2.3., below. C2.2.6.5.2. Example: Carrier Destination Geographic Location Code. Here, "Carrier" is the entity, and the property modifier is "Destination." While "Destination" does further modify "Geographic Location Code," it should not be merged to form a new generic element because "Destination" does not restrict the domain or structure of "Geographic Location Code." (See paragraph C2.3.1., below.) C2.3. GENERIC ELEMENT C2.3.1. A generic element is the part of a data element that establishes a structure (maximum size/length and data type) and limits the allowable set of values of a data element. A generic element has no functional or application context other than to define a general class of data and ensure consistency in structure and domain. The domain (permissible set of values) of a generic element may be specific or general. C2.3.2. Each data element must include one and only one generic element to identify the class of data and the allowable values that may represent the data element. A data element may use all or part of the generic element domain, but may not exceed the domain. C2.3.3. A generic element consists of a class word and, if necessary, modifiers. Example: The data element "Individual Citizenship Month Code" in which the generic element is "Month Code." Data element name: Individual Citizenship Month Code Data element domain: 01 - January 02 - February 03 - March Etc. C2.3.4. A genetic element may consist of only a class word (i.e., a single word generic element that establishes the structure and range of values for a data element). For example, the single word generic element "Name" consists only of a class word and is defined as: "A designation of an object or entity expressed in a word or phrase." The established domain for the generic element "Name" or a subset of that domain can be used to form many data elements. Example: Generic element name: Name Generic element domain definition text: A general domain compromised of the Alphabetic characters in the ASCII Character set Data element name: Individual Eye Color Name Data element domain definition text: A specific domain compromised of the ASCII characters: A-Z Data element domain value identifier: Blue Brown Gray Green Hazel C2.4. DOMAIN A domain is a set of valid data values approved for use with generic element or a data element. Domains for generic elements and data elements must be approved by the data steward (a designated Functional Administrator (FDAd)) of the element. A domain can be either specific or general. C2.4.1. Specific Domain. A specific domain has a finite definition and an enumerable set of data representations as shown in the example below. A specific domain is defined by naming the acceptable values allowed in a prescribed set of data representations. Example: Data element name: Individual Eye Color Name Data element domain domain value identifier: Blue Brown Gray Green Hazel C2.4.2. General Domain. A general domain has a broad definition and a large (possibly infinite) set of acceptable values that cannot be enumerated within reason. A general domain is described by establishing a set of possible values, but does not list all the possible values. Certain values or characters may be restricted. An example of a general domain is shown below: Example: Data element name: Individual Pulse Rate Data element domain Definition text: A general domain compromised of the ASCII characters 0-9. C2.5. METADATA C2.5.1. Data elements have definitive characteristics that quantify, identify, or describe a representational, administrative, or relational concept. Metadata are data about data. In the context of data elements, metadata are data (or facts) about data elements or generic elements. C2.5.2. Generic elements and data elements are maintained in the Defense Data Repository System (DDRS) and are described by metadata. For example, generic elements and data elements and data elements have names, definitions, and domains. Unit of measure, e.g., feet, tons, miles per hour, etc., is also a characteristic of a data element and such is an item of metadata. C2.5.3. A list and description of DDRS metadata is provided in Appendix 2. C2.6. DATA ELEMENTS STANDARDIZATION PHASES Generic elements and data elements evolve through the following standardization phases (prime words and class words have corresponding phases). C2.6.1. Developmental. Generic elements and data elements that have been created but not yet been released by the originator for standardization review. The requirement for a data element is normally identified during data modeling or through analyzing new functional requirements such as those required by new legislation. (See Chapter 3, below.) C2.6.2. Candidate. Generic elements and data elements that have been submitted by the Logistics Functional Data Administrator (FDAd) or Component Data Administrator (CDAd) for formal review. (See Chapter 4, below.) C2.6.3. Approved. Generic elements and data elements that have been coordinated through the standardization process as specified in Chapter 5. C2.6.4. Disapproved. Generic elements and data elements that have been coordinated through the standardization process specified in Chapter 5, and whose use has been disapproved. C2.6.5. Modified. Generic elements and data elements that were previously approved and are currently being considered for change. These elements go through the same formal review as candidate standard generic and data elements. (See Chapter 6, section C6.3.) C2.6.6. Archived. Generic elements and data elements that were formerly approved, but are no longer needed to support the information needs of the Department of Defense. (See Chapter 6, section C6.4.) C3. CHAPTER 3 DATA ELEMENT DESIGN, DEFINITION, AND NAMING C3.1. PURPOSE This chapter provides guidance for designing, defining, and naming data elements that can be used throughout the Department by multiple functional communities. Implementation of this guidance is covered under the processes discussed in Chapters 4, 5, and 6, below. C3.2. DATA ELEMENT DESIGN The quality of the data element is the key to the sound foundation for all data structures. Proper emphasis on the creation, naming, and definition of data elements will improve the quality of the entire data structure. Standard data elements should be based upon the data entities and data entity attributes identified in the DoD data model, or recommended for expansion of the DoD data model from a lower level data model, to ensure maximum shareability and interoperability of data throughout the Department of Defense. Several considerations are important to the quality of the data element. C3.2.1. Data elements must be designed: C3.2.1.1. To represent the attributes (characteristics) of data entities identified in data models. A model-driven approach to data standards provides a logical basis for and lends integrity to, standard data elements. C3.2.1.2. According to functional requirements and logical, and not physical, characteristics. Physical characteristics include any connotations regarding technology (hardware or software), physical location (databases, records, files, or tables), organization (data steward), or application (systems, applications, or programs). C3.2.1.3. According to the purpose or function of the data element rather than how, where, and when the data element is used or who uses it. It indicates what the data element represents and ensures common understanding. C3.2.1.4. So that it has singularity of purpose. Data elements must not have more than one meaning. A data element should reflect a single concept to promote shareability and data independence from applications using the data element. C3.2.1.5. With generic element values (domain) that are mutually exclusive and totally exhaustive when the class word "Code" is used. C3.2.2. Data elements should not be designed with: C3.2.2.1. Value (domain) that may be confused with another value in the same domain. For example, mixing similar numbers and letters such as 0/O, 1/l, 2/Z, U/V, and 5/S. C3.2.2.2. Values (domain) that have embedded meaning or intelligence within part of the code when the class word "Code" is used. For example, do not develop a multiple-character code wherein the value of one or more of the characters in the code have special meaning (i.e., a benefits plan code such as "201," "202," "204," or "205," where the last digit identifies a particular option within the benefit plan). C3.2.2.3. Overlap or redundancy among the purpose or use of different data elements (e.g., "Birth Date," Current Date," and "Age"). C3.3. DATA ELEMENT DEFINITION The definition and naming of a data element is an iterative design process with the data element definition often being modified as the data element is being developed. C3.3.1. Data element definitions must: C3.3.1.1. Be based on the definitions of data entity attributes established in the DoD data model or established in an approved data model linked (mapped) to the DoD data model. C3.3.1.2. Have a structure that centers around the generic element of the data it describes. Developing a standard data definition using a structure minimizes "writers block" and facilitates the development of consistent and meaningful definitions that can be accepted by all users. C3.3.1.3. Define WHAT the data is, not HOW, WHERE, or WHEN data are used or WHO uses the data. C3.3.1.4. Be more than just a reiteration of the data element name. The definition must add meaning to the name and not merely rephrase the name. The class word is an exception, its meaning does not need to be redefined in each definition. C3.3.1.5. Describe its purpose and usefulness and must not contain physical characteristics. The definition must describe logical, not physical, qualities. C3.3.1.6. Have one and only one interpretation and must not be ambiguous. Terms with differing or varying connotations must have their meanings clearly explained in the definition. C3.3.2. Data element definitions must not: C3.3.2.1. Contain conjunctions or phrases indicating multiplicity of purpose of a data element, ambiguity of definition, or process orientation. C3.3.2.2. Contain technical jargon that may be unfamiliar to the reader. C3.3.2.3. Contain acronyms and abbreviations. C3.3.2.4. Restate the characteristics of the data element. For example, do not use statements or phrases such as "... seven characters in length..." or "... an alpha-numeric code..." in the definition. C3.3.2.5. Restate a process definition that describes how a data element is calculated, derived, assimilated, or manipulated. C3.3.2.6. Contain information about the valid values or domain of the data elements. C3.3.2.7. Be circular. A situation cannot exist where one definition points to a second definition for further explanation and the second definition points back to the original definition. C3.4. DATA ELEMENT NAMING The set of guidelines for naming data elements establishes a naming convention, or classification scheme, that will make it easier to determine if a data requirement is already being met within the Department of Defense or if it is a new requirement that needs to be fully defined and the data collected and distributed as necessary. C3.4.1. The names of data elements should: C3.4.1.1. Be based on the names of data entity attributes identified in the DoD data model or an approved data model linked (mapped) to the DoD data model. C3.4.1.2. Be clear, accurate, and self-explanatory. C3.4.1.3. Be named according to logical, and not physical considerations. Physical characteristics include any connotations regarding technology (hardware or software), physical location (databases, files, or tables), organization (data steward), or function (systems, application, or programs). C3.4.1.4. Consist of the minimum number of words that categorize the data element. Fewer words may be too general while more words may be too narrow or restrictive. Modifiers may be used with class words, generic elements, and prime words to fully describe generic elements and data elements. Modifiers are often derived from the data entity attribute names and the entity names identified in the DoD data model or an approved model linked (mapped) to the DoD data model. C3.4.1.5. Include only alphabetic characters (A-Z, a-z), hyphens (-), and spaces ( ). C3.4.1.6. Have each component of the name separated by a space. C3.4.1.7. Have multiple-word prime words connected with hyphens. Examples of multiple prime words might be "Purchase-Order," "Medical-Facility," or "Civilian-Government." C3.4.2. The following are not permitted in data element names: C3.4.2.1. Words that redefine the data element or contain information that more correctly belongs in the definition. C3.4.2.2. Class words used as modifiers or prime words. C3.4.2.3. Abbreviations or acronyms. (Exceptions to this rule may be granted by the DoD DAd in the case of universally accepted abbreviations or acronyms. The DDRS will contain a list of approved abbreviations and acronyms.) C3.4.2.4. Names of organizations, computer or information systems, directives, forms, screens, or reports. C3.4.2.5. Titles of blocks, rows, or columns of screens, reports, forms, or listings. C3.4.2.6. Expression of multiple concepts, either implicitly or explicitly. C3.4.2.7. Plurals of words. C3.4.2.8. The possessive forms of a word; i.e., a word that denotes ownership. C3.4.2.9. Articles (e.g., a, an, the). C3.4.2.10. Conjunctions (e.g., and, or, but). C3.4.2.11. Verbs. C3.4.2.12. Prepositions (e.g., at, by, for, from, in, of, to). C4. CHAPTER 4 LOGISTICS DATA ELEMENT DEVELOPMENT PROCEDURES C4.1. INTRODUCTION C4.1.1. Data requirements are identified by users of logistics information who need to make decisions or conduct operations, or by system developers who support users. Data elements are not developed by data administrators or users working in isolation. Data elements are developed by users working together with logistics functional experts and data administrators to assist in defining and meeting the user's data requirements. In many cases it will be discovered that the users requirement is already being met within the DoD Logistics Community and the problem is to make the data available only to the "new" user of the data element. A quick review of standard data elements in the DDRS can often result in identification of a data element that meets the user's requirement and saves development time. C4.1.2. Data elements are named in the context of the organization's data model and with a view towards integration of the data element into the DoD data model. Awareness of the DoD data model will facilitate naming data elements, help avoid duplication, and support consistency throughout the Department of Defense. C4.2. PURPOSE C4.2.1. The procedures presented in this Chapter have been established to facilitate the efficient development of DoD Logistics standard data elements. After completing these procedures, data elements will be ready to enter the DoD data element standardization approval process. C4.2.2. These procedures are applicable when developing new DoD Logistics standard data elements, reverse engineering, or reengineering existing logistics data elements in migration or other existing systems to develop DoD standard data elements. C4.2.3. Before going through the development of a logistics standard data element it is wise to have a complete understanding of the data requirement. A quick review of existing DoD standard data elements might result in finding the standard data element already exists. The standard data element should then be used, or if necessary, a modification to it can be prepared. This can save considerable time and effort. If no adequate standard data element exists, the steps outlined below should be followed. C4.3. ASSEMBLE SOURCE DOCUMENTATION C4.3.1. Gather all available documentation that may provide information for, or assist in, completing the DoD Logistics standard metadata of the generic element(s) and/or data element(s) to be proposed for standardization. The DoD data model and the DDRS are primary sources of information for developing a DoD Logistics standard data element. Additional references and resources including the following: C4.3.1.1. Functional information resources. C4.3.1.2. Functional or component data models and process models. C4.3.1.3. Functional and Component data dictionaries that may exist. C4.3.1.4. Federal information processing standards (FIPS). C4.3.1.5. "Dictionary of Business Terms." C4.3.1.6. Unabridged dictionary. C4.3.1.7. U.S. Military Dictionary (Dictionary of Military Terms/Acronyms). C4.3.1.8. Thesaurus. C4.3.1.9. Notes from interviews with business and systems analysts. C4.3.1.10. DoD Publications, Manuals, Directives and/or Instructions. C4.3.1.11. System documentation. C4.3.1.12. Technical writing guide. C4.3.1.13. DDRS End User Manual. C4.3.2. A data element development worksheet may be prepared for documenting data element attributes. On-line development of data elements in the DDRS is strongly encouraged. C4.3.3. Access to the DDRS may be direct or through functional dictionaries or Component dictionaries. C4.4. IDENTIFY PRIME WORD NAME (MANDATORY) WITH MODIFIER NAME(S) (OPTIONAL) C4.4.1. Identify Prime Word Name C4.4.1.1. From the DoD data model, identify the data entity of the attribute for which the data element is being developed (e.g., airport, individual, vehicle). These are represented by the prime words listed in the DDRS. C4.4.1.2. If no entity in the DoD data model seems appropriate, a candidate DoD data model entity must be prepared and submitted through the appropriate CDAd or FDAd to the DoD DAd. The candidate entity will often come from a lower level data model that maps to the DoD data model, and will be the source of the prime word. The candidate standard data element may be prepared and submitted simultaneously with the candidate entity submission. C4.4.2. Identify Prime Word Modifier Name(s) C4.4.2.1. The addition of modifiers to further describe the data entity for which data is to be collected is optional. C4.4.2.2. The number of prime word modifiers should be minimized. C4.4.2.3. The modifiers are normally selected from the entity names of the next two higher level entities in the DoD data model. C4.4.2.4. The DDRS contains a list of modifiers that have been previously been approved. This restricted vocabulary should be used whenever possible. C4.4.3. Combine the prime word modifier name(s) and the prime word name. Order multiple modifiers from right to left, general to specific. (See "Data Element Naming Rules" in Chapter 3, section C3.4., above.) C4.4.4. There may be times when a prime word modifier more logically should follow the prime word rather than precede it. This is allowable but should be done with discretion. These modifiers were referred to as property modifiers in Chapter 2. C4.5. DEVELOP DEFINITION OF PRIME WORD AND MODIFIERS C4.5.1. Review the definitions of the data entity in the source data model and the associated attribute for which the data element is being developed and relate it to the associated data entity in the DoD data model. C4.5.2. Formulate a definition for the prime word with its modifier(s). C4.5.3. Make the definition a logically sequenced, grammatically and structurally correct, simple sentence. (See "Data Element Definition Rules" in Chapter 3, section C3.3.) C4.5.4. Edit and refine the definition according to the standards of English writing. C4.6. DEVELOP GENERIC ELEMENT NAME (MANDATORY) C4.6.1. Identify Class Word Name C4.6.1.1. Identify the category of data associated with the data entity attribute for which the data element is being developed (e.g., code, name, and amount). This will come from the class word name list contained in Appendix 1. C4.6.1.2. If no class word on the list seems to be appropriate, a candidate word may be submitted through the appropriate CDAd or FDAd to the DoD DAd. The candidate standard data element may be prepared and submitted simultaneously with the candidate class word submission. C4.6.2. Identify Class Word Modifier Name(s) C4.6.2.1. The addition of modifiers to further describe and restrict the category of data to be collected is optional. C4.6.2.2. A minimum number of words should be selected as modifiers to describe the class word name. C4.6.2.3. The modifiers should be selected from the data entity attribute name in the DoD data model whenever possible. C4.6.2.4. The DDRS contains a list of modifiers that have previously been approved. This restricted vocabulary should be used whenever possible. C4.6.3. Combine the class word modifier name(s) and the selected class word name to form the generic element name. Order multiple modifiers from right to left, general to specific. (See "Data Element Naming Rules" in Chapter 3, section C3.4.) C4.7. DEVELOP GENERIC ELEMENT DEFINITION (MANDATORY) If the standard generic element already exists, go directly to section C4.9., below. C4.7.1. Select the generic element definition structure for the class word to be used in the generic element. (See Appendix 1.) C4.7.2. Formulate a definition for the class word modifiers and incorporate the modifier definition into the generic element definition structure. C4.7.3. Make the definition a logically sequenced, grammatically and structurally correct, simple sentence definition. (See "Data Element Definition Rules" in Chapter 3, section C3.3.) C4.7.4. Edit and refine the generic element definition according to acceptable English writing conventions. C4.8. IDENTIFY GENERIC ELEMENT NAME (MANDATORY) WITH PROPERTY MODIFIER (OPTIONAL) C4.8.1. Sometimes generic elements require additional modifiers. These were referred to as property modifiers in Chapter 2. C4.8.2. The addition of such modifiers is optional and should be avoided whenever possible. C4.8.3. The DDRS contains a list of modifiers that have previously been used. This restricted vocabulary should be used whenever possible. C4.8.4. Combine the property modifier(s) and the generic element name. C4.8.5. Unit of measure is not allowed as part of a generic element name. C4.9. DEVELOP DEFINITION OF GENERIC ELEMENT AND MODIFIER(S) C4.9.1. Formulate a definition for the generic element modifier(s) and incorporate the modifier(s) definition with the generic definition structure. C4.9.2. Make the definition a logically sequenced, grammatically and structurally correct, simple sentence definition. (See "Data Element Definition Rules" in Chapter 3, section C3.3.) C4.9.3. Edit and refine the generic element with modifier(s) definition according to acceptable English writing conventions. C4.10. DEVELOP DATA ELEMENT NAME (MANDATORY) C4.10.1. Combine the prime word name with its modifier(s) and the generic element name with its modifier(s) to form the data element name. (See "Data Element Naming Rules" in Chapter 3, section C3.4.) C4.10.2. Ensure that the domain of the data element is consistent with, or a subset of, the domain of the generic element. C4.11. DEVELOP DATA ELEMENT DEFINITION (MANDATORY) C4.11.1. Incorporating the prime word with modifier(s) definition into the generic element with modifier(s) definition. C4.11.2. Make the definition a logically sequenced, grammatically and structurally correct, simple sentence definition. (See "Data Element Definition Rules" in Chapter 3, section C3.3.) C4.11.3. Edit and refine the data element definition according to the standards of English writing. C4.12. RESEARCH EXISTING ELEMENTS C4.12.1. Following the procedures in the DDRS End User Manual, search the DDRS to locate generic element(s) having a name the same as, or similar to, the generic element name just developed. C4.12.2. If no approved, modified, candidate, or archived generic element is identified, continue development of a new generic element (section C4.13.). C4.12.3. For each generic element found in the DDRS, list the standard data elements in the DDRS whose names contain the same or similar prime word with modifier(s) name. C4.12.4. Compare the name being developed with the names on the list from the DDRS. C4.12.5. Identify the name of each data element from the DDRS that describes the same concept as the name being developed. C4.12.6. Compare the definition of the data element under development with the definition of each data element identified in the step C4.12.5., above. C4.12.7. Identify the name of each data element having a matching definition. C4.12.8. Review the value domain of each data element identified in step C4.12.7., above. C4.12.9. Identify the name of each data element having a domain, that either matches, includes all of the values of (superset), or approximates the intended domain of the data element under development. If more than one is identified, determine which represents the data, element under development. C4.12.10. Review the mandatory attributes of each data element identified in step C4.12.9., above. C4.12.11. Identify the name of each data element having required attributes that either match or approximate the intended attribute values of the data element under development. C4.12.12. Select the data element from the previous step having mandatory attribute values nearest those of the data element under development. This procedure should result in no more than one approved, modified, candidate or archived data element. C4.12.13. If no data element will fulfill the requirements of the data element under development, continue development of the new data element (see section C4.13.). C4.12.14. If an approved, modified, or candidate data element will fulfill the requirements of the data element under development, prepare and submit the attributes required to register a new application of the existing data element according to the procedures in Chapter 6, section C6.2. C4.12.15. If an approved or archived data element can be modified to fulfill the requirements of the data element under development, prepare the required modifications to the selected element and submit these changes to the appropriate FDAd or CDAd for coordination and preliminary review, as described in Chapter 5. C4.12.16. If an archived data element will fulfill the requirements of the data element under development, reinstate the archived data element according to the procedures in Chapter 6, section C6.5. C4.13. IDENTIFY GENERIC ELEMENT DOMAIN (MANDATORY) Skip section C4.13., if a new generic element is not being developed. C4.13.1. Record the generic element domain definition text to describe the overall meaning or general characteristics of the generic element domain. C4.13.2. For a generic element with a specific domain, record each value (generic element domain value identifier) and the definition for each value (generic element domain value definition text). (If the domain is excessively large, an extract sample list should be given along with the source document for the complete list in lieu of the entire domain list.) C4.13.3. For all quantitative class words, record the allowable range of the domain values (generic element low-range identifier and generic element high-range identifier). C4.14. RECORD REMAINING GENERIC ELEMENT ATTRIBUTES Skip section C4.14., if a new generic element is not being developed. Record values for each of the remaining mandatory attributes and any appropriate optional attributes for the new generic element. Refer to the detailed standard generic element attribute descriptions in Appendix 2. C4.15. IDENTIFY DATA ELEMENT DOMAIN (MANDATORY) C4.15.1. Enter the data element domain definition text to describe the overall meaning or general characteristics of the data element domain. C4.15.2. For a data element with a specific domain, enter each value (standard data element domain value identifier) and the definition for each value (standard data element domain value definition text). The domain values must be the same or a subset of the domain values of the associated generic element. (If the domain is excessively large an extract sample list should be given along with the source document for the complete list in lieu of the entire domain list.) C4.15.3. For all quantitative class words (see Appendix 1), enter the allowable range of the domain values (standard data element low-range identifier and standard data element high-range identifier). The low-range and high-range values must be equal to or a subset of the low-range and high-range values of the associated generic element. C4.15.4. If a standard generic element exists that contains some, but not all the domain values of the data element being developed, prepare and submit the required modifications as a modified standard generic element. The candidate standard data element may be prepared and submitted simultaneously. C4.16. RECORD REMAINING DATA ELEMENT ATTRIBUTES Record values for each of the remaining mandatory attributes and any appropriate optional attributes for the data element. Refer to the detailed standard data element attribute descriptions in Appendix 2. C4.17. SUBMIT PROPOSED ELEMENT(S) FOR APPROVAL Submit the developmental generic element and/or data element information to the appropriate FDAd or CDAd for coordination and preliminary review, as described in Chapter 5. C5. CHAPTER 5 STANDARDIZATION APPROVAL PROCESS C5.1. PURPOSE This Chapter describes the procedures to be used when generic elements or data elements are being considered for adoption as approved standards. The approval process for data elements and generic elements is identical. Prime words and class words have a corresponding process. All references to "data element" in this chapter pertain equally to generic elements and data elements except where noted separately. C5.2. COORDINATION PROCEDURES C5.2.1. Any DoD information system user or developer within the Department of Defense may propose a data element for standardization and submit it through Component or functional channels for approval. C5.2.1.1. Data elements originated in support of the functional area of logistics will be processed, in accordance with the procedures established by the logistics FDAd. These procedures must conform to the policies and procedures of DoD Directive 8320.1 (reference (o)). The logistics FDAds may require their respective functional users or system developers to submit development data elements into a functional data dictionary, a functional partition of the DDRS, or require that they be submitted to the Logistics FDAd in a prescribed electronic or non-electronic format. C5.2.1.2. Developmental data elements originated in support of a DoD Component requirement will be processed within the Component in accordance with the procedures established by the CDAd. These procedures must conform to the policies and procedures of DoD Directive 8320.1 (reference (o)). The CDAds may permit their Component users or system-developers to enter developmental data elements into a Component data dictionary, a Component partition of the DDRS, or require that they be submitted in a prescribed electronic or non-electronic format. C5.2.2. The CDAd will review developmental data elements proposed at the DoD Component level to ensure compliance with the rules and procedures described in Chapters 3 and 4, above, before submitting the data element as a candidate standard. The Component's functional representatives are encouraged to discuss the data element with their DoD functional counterparts before submitting the data element to the CDAd and during Component review. C5.2.3. The Logistics FDAd will review the developmental data elements proposed at the OSD functional level to ensure compliance with the rules and procedures described in Chapters 3 and 4 before submitting the data element as a candidate standard. The FDAd will discuss the data element with functional counterparts in the Components before submitting the data element as a candidate standard data element. C5.3. PRELIMINARY REVIEW Developmental logistics data elements will be reviewed in accordance with Component and/or functional procedures for adherence to technical and functional requirements before being forwarded to the Logistics FDAd for submission as candidate or modified standard data elements Logistics FDAd will validate and submit each developmental data element through the following process: C5.3.1. Review developmental data elements for adherence to the following technical and functional requirements: C5.3.1.1. The data element requirement must be derived from a data model approved by ADUSD(L)(LBS&TD) that can be mapped to the DoD data model. C5.3.1.2. The definition of the data element must fully describe the data requirement and convey only one concept, as outlined in Chapter 3, above. C5.3.1.3. The data element name must conform to the data element naming guidelines described in Chapter 3, above. C5.3.1.4. The mandatory metadata attributes of the data element must be fully described. C5.3.1.5. The generic element associated with the data element must be contained in the DDRS in an approved, candidate, or modified status before the data element can be submitted as a candidate or modified standard data element; or a candidate or modified generic element must be developed and submitted at the same time as the data element. C5.3.2. Review developmental generic elements for adherence to the following technical and functional requirements: C5.3.2.1. The generic element is required in a developmental data element because no existing standard generic element is sufficient. C5.3.2.2. The definition of the generic element must describe the kind of data stored in all associated data elements. C5.3.2.3. The generic element name must conform to the data element naming guidelines described in Chapter 3. C5.3.2.4. The mandatory metadata attributes of the generic element must be fully described. C5.3.3. Return to the originator any data element that does not meet the criteria in Chapter 4, with the reason(s) for the rejection. C5.3.4. For data elements that meet the criteria in Chapter 4: C5.3.4.1. Confirm that a suitable data element does not already exist by reviewing all standard data elements in the DDRS that have the same or similar names or descriptions. (This includes archived standard data elements.) C5.3.4.2. If the attributes of the data element are identical or similar to a standard data element in the DDRS, return the developmental or modified data element to the originator for further review of the existing standard data element(s). C5.3.4.2.1. The developmental data element originator should review the existing standard data element(s) to determine if a new data element is required. If the existing standard data element is suitable, the originator may either use the existing standard data element, as defined, or propose a modification to the existing standard data element or an existing standard generic element. C5.3.4.2.2. If an existing standard data element is to be used as defined, the developer/user must identify the additional system(s) that will use the standard data element and request that the Logistics FDAd register the application(s) that use the standard data element in the DDRS. C5.3.5. Enter the validated developmental data element(s) into the DDRS as candidate or modified standard data elements to begin the approval process. The logistics FDAd designated as the data steward of each of the candidate standard data elements and the DoD DAd automatically will be notified that new candidate or modified standard elements are awaiting their review. C5.4. FORMAL REVIEW The DoD DAd and the Logistics FDAd must approve or disapprove the data element within 30-working days of notification that the candidate data element has been submitted for review. Requests for time waivers must be sent electronically to the DoD DAd with reason why more time is required. The DoD DAd and the designated FDAd (data steward) will conduct concurrent reviews of candidate standard elements as described, in paragraphs C5.4.1. and C5.4.2., below. The DoD DAd will allow a minimum of 20 working days before approving a data element to permit the Logistics FDAd time to review and comment on the data element. C5.4.1. Technical Review C5.4.1.1. The DoD DAd reviews the candidate or modified standard data element within 30 working days and determine if the candidate standard element conforms to DoD Data Administration policy and does not conflict with existing standard data elements. C5.4.1.2. The DoD DAd will review the data element metadata attributes for completeness and conformance with current DDRS technical requirements as specified in the DDRS End User Manual. C5.4.1.3. The DoD DAd will validate the data element by confirming conformance to the DoD data model. C5.4.1.4. Recommendation for technical approval will be annotated in comments on the data element in the DDRS. C5.4.1.5. Recommendation for technical rejection and supporting reasons will be annotated in comments on the data element in the DDRS for resolution by the designated data steward. C5.4.2. Functional Review C5.4.2.1. The Logistics FDAd reviews the candidate or modified standard data element within 20 working days for consistency within the functional area and for conformance with cross-functional integration requirements. The FDAd validates the data element metadata attributes to ensure that the data element is functionally accurate and complete. If the FDAd believes that some other FDAd should be the data steward, that change will be made and a comment explaining the rationale will be provided. The 20 working day review period begins again any time the data steward is changed. C5.4.2.2. The Logistics FDAd will coordinate with appropriate FDAds and CDAds to ensure that the data element will meet all functional and Component data requirements. The FDAd will coordinate efforts to resolve any technical deficiencies. The FDAd must review their functional area data model and assess the potential configuration changes. If another FDAd believes that the data steward designation was incorrectly made, an electronic comment should be immediately generated to the Logistics FDAd and the DoD DAd for resolution. C5.4.2.3. The Logistics FDAd must coordinate modified standard data elements with the other FDAds and functional counterparts within the Components that will be affected by the change to the existing data element. Users of the existing standard data element are indicated by the information systems registered in the DDRS as application of the standard data element. C5.4.2.4. The Logistics FDAd does not obtain concurrence from all respondents, the FDAd may still elect to approve the data element. All non-concurrences, however, must be noted in the DDRS for review by the DoD DAd. The issue may be brought to the attention of the DoD DAd for resolution or elevated to a higher level for resolution as discussed in paragraph C5.4.3.1., below. C5.4.2.5. If the Logistics FDAd determines that the data element is not consistent with, or conflicts with, existing standard or modified data elements within the functional area, the FDAd notifies the DoD DAd by annotating the reasons for rejection in the DDRS. C5.4.2.6. If no conflicts exist, the Logistics FDAd recommends approval of the data element and notifies the DoD DAd by annotating the approval in comments on the data element in the DDRS. C5.4.3. DoD DAd Evaluation and Final Approval C5.4.3.1. The DoD DAd evaluates the recommendations from the technical and functional reviews and obtains consensus on a final recommendation within 10 working days after completion of the technical and functional reviews. C5.4.3.1.1. If the technical and functional review recommendations are not the same, the DoD DAd will coordinate with the FDAd to resolve the conflict. C5.4.3.1.2. If the conflict cannot be resolved by the DoD DAd, the DoD DAd will forward the issue, together with respective recommendations, to the Directorate of Defense Information (DDI), DISA, for resolution. C5.4.3.1.3. If the conflict cannot be resolved by the DDI it will be forwarded to the DoD Senior Information Resource Management (IRM), DISA, official for final resolution. C5.4.3.2. When the final recommendation is for approval, the status of the data element is changed to approved. C5.4.3.3. When the final recommendation is for disapproval, the status of the data element is changed to disapproved and the Logistics FDAd that submitted the data element is automatically notified of the disapproval. After notification of disapproval, the submitting FDAd may either delete the data element from the DDRS or make appropriate changes and resubmit the data element. C6. CHAPTER 6 DATA ELEMENT MAINTENANCE PROCEDURES C6.1. PURPOSE Approved standard generic and data elements can be implemented or modified for use in various applications or information systems, or they may be archived when no longer required. Archived standard generic and data elements may be reinstated for use. The following maintenance procedures describe the processes for registering use of a data element by an application, modifying approved data elements, archiving standard generic and data elements, and reinstating archived standard generic or data elements. C6.2. REGISTERING DATA ELEMENT APPLICATIONS All new information systems and migration information systems must be registered in the DDRS. Upon completion of the system interface definition prescribed by MIL-STD-2167-A (reference (s)) or database specifications prescribed by DoD Directive 7935.1 (reference (t)), data element attributes in the DDRS must be updated to identify the information system(s) and/or application(s) using each standard data element. Register applications of each standard data element according to the following procedures. More detailed procedures can be found in the DDRS End User Manual (reference (p)). C6.2.1. New Applications and/or Information Systems and Migration Systems Using Standard Data Elements C6.2.1.1. Record the standard data element name for which the application is being registered. C6.2.1.2. Record the standard data element component code. C6.2.1.3. Record the identification of the application ("Automated information software system identifier"). C6.2.1.4. Record the name of the application ("Automated information software system name"). C6.2.1.5. Record the standard data element access name. C6.2.2. Migration Systems Not Using Standard Data Elements. This information is required to assist in the evolutionary transition to the use of standard data elements. C6.2.2.1. Data migration information systems will be registered as application data elements by the Component or OSD staff owning the migration information system(s). C6.2.2.2. Review the DDRS to identify the DoD standard data element corresponding to the existing system data element, if one exists; if none exists, go to section C6.5., below. C6.2.2.3. Record the DoD standard data element name for which the application is being registered. C6.2.2.4. Record the standard data element component code. C6.2.2.5. Record the identification of the application ("Automated information software system identifier"). C6.2.2.6. Record the name of the application ("Automated information software system name"). C6.2.2.7. Record all variances between the metadata attribute values of the data element for which the application is being registered and the metadata attribute values of the standard data element. (This might include a formula or algorithm used to derive the data element.) C6.2.2.8. Record the data element attributes (metadata) that do not correspond to the standard data element. C6.2.2.9. Record data element access name. C6.2.2.9.1. Data element access names provide the direct link between the standard data elements defined in the DDRS and the application of those standard data elements in automated information systems. C6.2.2.9.2. The length of access names (i.e., identification of data fields in database and file structure) is important to analysts, designers, and programmers who must produce documentation and program code using standard data elements. C6.3. MODIFYING EXISTING STANDARD DATA ELEMENTS C6.3.1. Modifications may be proposed for any standard data element. The conventions, rules, guidelines, and procedures that apply to developmental data elements also apply to proposed modifications of standard data elements. C6.3.2. Based on the attributes of the standard data element to be modified, follow the same procedure as for creating a developmental data element (Chapter 4) using the steps relating to the data element(s) proposed for modification. A review of the standard data elements in the DDRS may preclude the need to develop a modified standard data element. C6.3.3. The current version of the standard data element being modified will be automatically archived upon approval of the modified standard data element. C6.4. ARCHIVING STANDARD DATA AND GENERIC ELEMENTS Standard data elements and their associated generic elements may be changed to an archived status based on the recorded use of the standard data elements. The archived standard generic and data elements are retained in the DDRS for historical reference and possible reinstatement based on changing functional information requirements. Standard generic elements and data elements are changed to an archived status through the following process: C6.4.1. Standard Data Elements C6.4.1.1. The Logistics FDAd will identify standard data elements that are no longer used or needed by information systems based on changes in functional information requirements and notify the appropriate FDAd (data steward). C6.4.1.2. The Logistics FDAd will notify the affected CDAds and FDAds of standard data elements to be deleted from information systems supporting the respective Component or functional areas based on the using Components and using systems registered in the DDRS. C6.4.1.3. When the FDAd(s) establish the effective data for deleting a data element(s) from an information system(s), the data steward for the data element will notify the DoD DAd of the affected data element(s) and the effective date for deletion. C6.4.1.4. The DoD DAd will delete the affected information system(s) and associated Component(s) from the list of users registered in the DDRS on the effective date for deletion. C6.4.1.5. If no information systems or Components remain on the list of users registered in the DDRS for a standard data element, the DoD DAd will notify the appropriate FDAd (data steward) and recommend that the standard data element be archived. C6.4.1.6. Based on the DoD DAd recommendation to archive a standard data element, the FDAd will assess the functional or technical need to retain the standard data element. C6.4.1.7. If the FDAd determines that the standard data element should not be archived, the data steward will notify the DoD DAd to retain the standard data element in the DDRS in its existing status rather than archiving it. C6.4.1.8. If the FDAd determines that there is no technical or functional need to retain the standard data element, the data steward will notify the DoD DAd to change the status of the standard data element to an archived standard data element. There will be a general announcement in the DDRS when this is to occur. C6.4.2. Standard Generic Elements C6.4.2.1. When a standard data element is archived, the DoD DAd will review the list of remaining standard data elements associated with the corresponding standard generic element. C6.4.2.2. If there are no remaining standard data elements associated with the corresponding standard generic element, the DoD DAd will assess the functional or technical need for retaining the approved standard generic element. C6.4.2.3. If the DoD DAd determines that the approved standard generic element should be retained, the approved standard generic element will remain in the DDRS. C6.4.2.4. If the DoD DAd determines that the approved standard generic element should not be retained, the DoD DAd will change the status of the approved standard generic element to an archived standard generic element. There will be a general announcement in the DDRS when this is to occur. C6.5. REINSTATING ARCHIVED STANDARD DATA AND GENERIC ELEMENTS A review of the DDRS during the Logistics data element development or modification process may locate an archived standard data element that is suitable for use. In such a case, the archived standard data element and the associated standard generic element, if necessary, should be reinstated. Archived standard generic and data elements may be reinstated for use through the following process: C6.5.1. Notify the Logistics FDAd (data steward) that the archived standard data element exists and recommend that the archived standard data element be reinstated as a standard data element. C6.5.2. The FDAd will review the archived standard data element for applicability and accuracy. C6.5.3. If the archived standard data element is accepted by the data steward, the data steward will notify the DoD DAd that the archived standard data element and the associated standard generic element, if necessary, is to be reinstated and the effective date for reinstatement. C6.5.4. Based on the approval and notification by the data steward, the DoD DAd will change the status of the archived standard data element and its associated standard generic element, if necessary, to an approved standard data element and an approved standard generic element, respectively. C6.5.5. After the archived standard data element has been reinstated as an approved standard data element, the application using the reinstated standard data element must be registered in the DDRS, as described in paragraph C6.2.1., above. C7. CHAPTER 7 ANSI ASC X12 TRANSACTION SETS/DATA SEGMENTS/DATA ELEMENTS C7.1. PURPOSE/APPLICABILITY C7.1.1. The Defense Logistics Management System (DLMS) uses the American National Standards Institute's Accredited Standards Committee X12 (ANSI ASC Xl2) standards for EDI to exchange DoD Logistics data. The ASC X12 standards are formally established, maintained, and published under ASC X12 to provide a common basis for communicating shared business information. C7.1.2. The ASC X12 standards define the specific rules of syntax for using EDI constructs and defines the universe of components that can be used. However, because the X12 standards are intentionally designed to be very flexible to meet the need of a wide variety of users, additional documentation is necessary to define how to use the standards within a specific user community. This documentation is called implementation conventions. C7.1.3. The implementation conventions define for the DLMS which ASC X12 transaction sets are used. Within each transaction set they define the segments, data elements, and codes which are used. Most importantly, they also define specific rules and formats for the contents of data within the data elements. C7.1.4. The DLMS implementation conventions are organized by logistics functional area: supply, transportation, finance, acquisition, requirements, and maintenance. The purpose of this chapter is to assist the reader in understanding the basics of ASC X12 EDI standards. It defines X12 structure, terms, and concepts as applied under the DLMS. C7.2. DATA ELEMENT C7.2.1. The data element is the smallest named unit of information in the standard. They are identified as either simple or component. The context in which the data element is used determines which of these types apply. Data elements that are connected to form a composite data element structure are referred to as components. Use of composite data elements within the DLMS is very limited and their structure is discussed separately below. C7.2.2. Data elements are uniquely identified by reference number. Data elements within a segment are also identified by the segment identifier and position within the segment. Data elements appear in a predefined sequence within a segment as established by the standard. Data elements may be used in more than one segment and multiple occurrences of the same data element may be used in the same segment. C7.2.3. Basic attributes of a data element are length and type. C7.2.3.1. Data Element Reference Number. The data element reference number is a unique one to four digit number used to identify data elements within the ASC X12 data element dictionary. The number corresponds to the sequence of the data element as it occurs within the dictionary. C7.2.3.2. Data Element Type. Data elements are identified by type as follows. The symbol used to designate type is shown in parentheses. C7.2.3.2.1. Numeric (Nn). A numeric data element is represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data. The symbol for this data element type is Nn where "N" indicates that it is numeric and "n" indicates the number of decimal positions to the right of the implied decimal point. If no decimal positions are allowed, the symbol is written as N. A leading minus sign (-) is used to express negative values. Absence of a sign indicates positive value. Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional minus sign. For example, where the numeric type is N2 (indicating an implied decimal placement two positions from the right), the value -123.4 would be transmitted as -12340. The length of the value within the data stream is five. C7.2.3.2.2. Decimal Number (R). A decimal data element contains an explicit decimal point and is used for numeric values that have a varying number of decimal positions. The decimal point is always carried in the transmission unless it occurs at the right end of the value. A leading minus sign (-) is used to express negative values. Absence of a sign indicates positive value. Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point should be suppressed unless used to express precision. Use of commas within the numeric value is prohibited. The length of a numeric type data element does not include the optional minus sign or the decimal point. For example, the numeric value -1234.45 would be transmitted as -123.45. The length of this entry is five. C7.2.3.2.3. Identifier (ID). An identifier data element always contains a unique value from a predefined list of values maintained by ASC X12, the Department of Defense, or other responsible organization referenced by the data element dictionary. All code lists employed under DLMS including those maintained by ASC X12 are available via DoD LOGDRMS (see volume 1, References). The contents are left-justified and trailing spaces should be suppressed unless necessary to satisfy a minimum length requirement. Identifier type data elements are frequently used as qualifiers to identify by code the type of information contained in an associated data element. For example, the identifier type data element, Product/Service ID Qualifier, may be transmitted with a value of FS to indicate that the value contained in the associated data element Product/Service ID is a national stock number. In this instance, the list or identifier valid codes is maintained by X12. The conventions normally specify which of these values are permissible entries for the specific usage under DLMS. C7.2.3.2.4. String (AN). Contents of a string type data element are a sequence of letters, numbers, spaces, and/or special characters. The contents are left-justified and trailing spaces should be suppressed unless necessary to satisfy a minimum length requirement. The Product/Service ID mentioned in the above example is identified as a string-type data element. C7.2.3.2.5. Date (DT). A date data element is used to express the standard date in YYMMDD format in which YY is the year, MM is the month (01 to 12), and DD is the day of the month (01 to 31). C7.2.3.2.6. Time (TM). A time data element is used to express the time in HHMMSSd..d format in which HH is the hour for a 24-hour clock (00 to 23), MM is the minute (00 to 59), SS is the second (00 to 59) and d..d is the decimal seconds. Seconds and decimal second are optional. Trailing zeros in decimal seconds should be suppressed unless necessary to satisfy a minimum length requirement or unless necessary to indicate precision. C7.2.3.2.7. Binary(B). A binary data element is any sequence of octets ranging in value from binary 0000000 to 1111111. This data element type has no defined maximum length. Actual length is specified by the immediately preceding data element. The binary data element type may only exist in the Binary segment and is not used in the DLMS at this time. C7.2.3.2.8. Fixed-Length String (FS). A fixed-length string is a sequence of any characters. It must be space filled to satisfy its minimum length. Minimum and maximum values for any data element of this type must be equal and the data element must be mandatory in any segment in which it is used. Significant data shall be left justified (leading zeros are significant, trailing spaces are normally not significant). C7.2.3.3. Data Element Length. Each data element is assigned a minimum and maximum length. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements. A data element may be of variable length within the minimum/maximum range or it may be of fixed length in which the minimum is equal the maximum. Length is expressed by indicating both the minimum and maximum values separated by a slash, i.e., 2/30. C7.2.3.4. Data Element Reference Designator. Each simple data element or composite data structure in a segment is assigned a reference designator indicating the segment in which it is used and its sequential position within the segment. The reference designator is constructed from the segment identifier followed by the two-digit position number. Counting of the position number starts with 01 for the first data element appearing after the segment identifier and is incremented by one for each subsequent data element until the end of the segment. For example, the second data element in the N1 segment has a reference designator of N102. C7.2.3.5. Condition Designator. The condition designator (or requirement designator) is used to define the circumstances under which a data element is required to be present or absent in a particular usage. These conditions are of three basic types: mandatory, optional, and relational condition. Under DLMS, optional and relational condition designations can be further defined as either recommended or required. Condition designators are identified by symbol as specified in parentheses. C7.2.3.5.1. Mandatory(M). The designation of mandatory is absolute in the sense that there is no dependency on other data elements within the segment or composite data structure. A mandatory data element must appear in the segment. C7.2.3.5.2. Optional(O). The designation of optional means that there is no syntactic requirement for the presence of the data element within the segment or composite data structure. Optional data elements may be included or omitted based upon instructions provided by the conventions or at the discretion of the transmitting activity (as applicable). C7.2.3.5.3. Conditional(X). A relational condition defines a special relationship between two or more data elements within a segment or composite data structure. Relational conditions are based upon the presence of one of those data elements. The specific relationship is defined in a syntax note. The first character of the syntax note identifies one of the following conditions. Note that the ASC X12 segment directory diagrams use the symbol X in the lower left corner of the data element box to indicate that a relational condition applies. C7.2.3.5.3.1. Paired(P). If any specified data element is present, then all of the specified data elements must be present. C7.2.3.5.3.2. Required(R). At least one of the specified data elements must be present. C7.2.3.5.3.3. Exclusion(E). Not more than one of the specified data elements may be present. C7.2.3.5.3.4. Conditional(C). If the specified data element is present, then all other specified data elements must be present. However, any or all of the data elements not specified as the first in the condition may appear when the first is not present. C7.2.3.5.3.5. List Conditional(L). If the first specified data elements is present, then at least one of the remaining specified data elements must be present. However, any or all of the data elements not specified as the first may appear when the first is not present. C7.2.3.5.4. Recommended. The DLMS convention designation of recommended is used to further define an ASC X12 optional or conditional designation. It indicates that use of a specified data element is functionally advisable, but is not necessary for transmission of the transaction set. C7.2.3.5.5. Required. The DLMS convention designation of required is used to further define an ASC X12 optional or conditional designation. It indicates that use of a specified data element is optional according to the standards, but is necessary under the DLMS. C7.3. COMPOSITE DATA STRUCTURE C7.3.1. The composite data structure is an intermediate unit of information in a segment. It consists of two or more component data elements linked together to form a single data structure. Composite data structures are defined in an ASC X12 composite data structure dictionary. Use of composite data structures is very limited under DLMS. C7.3.2. Composite data elements are identified by a unique four-character reference identifier that corresponds to its location within the dictionary. The first character is alpha followed by three numerics assigned in sequence as composite data structures are created. An S in the first position indicates that the composite data structure is used in a control segment. A C indicates use in a data segment. C7.3.3. Component data elements within the composite data structure are assigned a condition designator that defines their requirement within the structure. C7.4. CODE SOURCES C7.4.1. Code values associated with data elements may be derived from several locations. C7.4.2. Many of the data elements under DLMS requiring use of specific code values list the appropriate code values in the conventions. C7.4.3. Three data entries, transportation mode/method (data element number 91, Transportation Method/Type Code), unit of issue (data element number 355, Unit or Basis for Measurement Code), and transportation type pack (data element 103, Packaging Code) use conversion guides shown at appendices 10B, 10C, and 10D, respectively. For ease of entry, the DLMS will continue to support the familiar code structures used in the DLSS. Special processing at the input provides conversion from DoD code value to ASC X12 value for transmission of the transaction set. Both the sender and the receiver employ the conversion guide so that the user sees only the familiar DoD code values. Where numerous code values are assigned to a particular data element and all are applicable to the application, specific codes may not be listed in the DLMS convention. Most code lists that are maintained by the Department of Defense or by ASC X12, and are used under the DLMS, are obtainable on-line through the automated DoD LOGDRMS. If the list of code values is too lengthy to include in the LOGDRMS data base, a reference for the code source will be provided. Each code source entry indicates the complete name of the responsible organization and where to obtain a list of codes. See Chapter 9 for access instructions. C7.5. INFORMATION SYSTEM The DoD LOGDRMS is the supporting information system that utilizes hierarchical and horizontal relationship criteria to fully define ANSI X12 data elements and relate those data elements to those established for DoD-wide use. See Chapter 9 for LOGDRMS User Guide. C8. CHAPTER 8 DOCUMENT IDENTIFIER (DI) CODE ASSIGNMENT CONTROL C8.1. AUTHORITY/PURPOSE C8.1.1. DoD Directive 4140.1-R (reference (l)) establishes the requirement for the DoD LOGDESMAP to "provide a common base of standard data elements for use throughout DoD Logistics Data Systems." The management and control of document identifier codes are critical to the development, control, and maintenance of DoD Logistics Systems. C8.1.2. This chapter provides procedural guidance and prescribes controls governing the: C8.1.2.1. Development of data codes to represent logistics document formats; C8.1.2.2. Use of such codes in logistics automated data systems and authoritative issuances; C8.1.2.3. Registration of these data codes, their meaning and usage in the DoD LOGDESMAP Data Bank; and C8.1.2.4. Publication of these data codes in DoD 4000.25-13-S2 (reference (d)), Listing of DoD Logistics Data System Transaction Documents. C8.2. SCOPE C8.2.1. These procedures govern: C8.2.1.1. Preparation, submission, and processing of requests for the reservation and allocation of series of document identifier codes for use in: C8.2.1.1.1. DoD-wide and Joint DoD Component Logistics Data Systems; or C8.2.1.1.2. Military Services or other DoD Component Logistics Data Systems when such use is prescribed by a DoD-wide or joint Service/Agency logistics system. C8.2.2. The registration, within the DoD LOGDESMAP Data Bank, of document identifier codes actually assigned within series reserved for DoD-wide and Joint DoD Component logistics data system use. C8.3. OBJECTIVES The procedures and controls described herein: C8.3.1. Provide essential guidance to organizational elements engaged in the development and maintenance of logistics data systems. C8.3.2. Provide visibility and control of the wide variety of logistics data system documents and their relationships. C8.3.3. Eliminate operational problems resulting from: C8.3.3.1. Duplication of DI codes for different formats; and C8.3.3.2. Lack of visibility and understanding of document formats and content. C8.4. DOCUMENT IDENTIFIER CODE SERIES RESERVATIONS The DoD LOGDESMAP Administrator maintains a listing of the various blocks of DI codes reserved for use in DoD-wide and Joint DoD Component Logistics Data Systems. C8.5. GUIDELINE CRITERIA C8.5.1. DI codes reserved for use in DoD-wide and Joint DoD Component Logistics Data Systems will not be assigned or used for any purpose other than that specified in the procedural documentation of such systems. C8.5.2. Requests for reservation and allocation of new series of DI codes for use in Joint DoD Component Logistics Data Systems will indicate that potential incorporation of the new document formats within existing DoD-wide Logistics Data Systems was fully considered prior to submission of the request. C8.6. PROCESSING OF REQUESTS FOR THE RESERVATION AND ALLOCATION OF DI CODE SERIES C8.6.1. Proponent organization of DoD-wide and Joint DoD Component Logistics Data Systems will: C8.6.1.1. Determine requirements for additional series of DI codes. (See paragraph C8.5.2., above, for supplementary action by proponent organizations of Joint DoD Component Logistics Data Systems.) C8.6.1.2. Prepare and submit correspondence to the DoD LOGDESMAP Administrator requesting reservation of a series of document identifiers. C8.6.2. The DoD LOGDESMAP Administrator will: C8.6.2.1. Reserve and allocate a series of DI codes as requested. C8.6.2.2. Notify the originating organization of the series of codes reserved. C8.6.3. Proponent organizations will: C8.6.3.1. Apply individual codes to document formats. C8.6.3.2. Incorporate the newly coded document formats in system documentation. C8.6.4. The DoD LOGDESMAP Administrator will: C8.6.4.1. Register the use of each DI code applied to a document format in the DoD LOGDESMAP Data Bank. C8.6.4.2. Distribute, as requested, listings of DI code assignments registered in the DoD LOGDESMAP Data Bank. C9. CHAPTER 9 DEPARTMENT OF DEFENSE LOGISTICS DATA RESOURCE MANAGEMENT SYSTEM (LOGDRMS) C9.1. CONFIGURATION C9.1.1. The DoD LOGDRMS is an on-line interactive database management system employing an IBM-compatible mainframe computer, Computer Corporation of America System 204 software and application program written in Model 204 user language. C9.1.2. On-line interactive capabilities are provided through availability and use of data terminals with direct access to the data bank. C9.1.3. Two types of terminals are used: C9.1.3.1. Hardwire to the central site, and C9.1.3.2. Dial-up (acoustic coupling) connection using conventional telephone lines. C9.1.4. Access to the central site requires the use of LOGON procedures including the use of passwords. Such passwords are the means for controlling unauthorized access to the database. C9.1.5. A variety of edits and validation checks are included in the interactive communication between the data terminal and the central bank to ensure compliance with established procedures and to prevent entry of invalid data or sets of data. C9.2. GENERAL LOGDRMS capabilities include options for viewing data from the terminal or printing the information in formatted reports. Accessing the system and obtaining the data requires the precise command entry in order to prevent system hang up or jamming. In most situations resulting from error in command entry, the system will respond with an error message, and reentry of the correct command. However, when the system stalls or hangs up, use a K or CANCEL command. If these fail, entry of CLOSE or LOGOFF commands may be used. The last resort is to disconnect from the system, wait for one minute and access the system from the initial point. C9.3. ACCESSING THE SYSTEM USING A PERSONAL COMPUTER AND MODEM C9.3.1. Connect to the DASC modem pool using a communications software package preferably PROCOMM PLUS. Protocol information as follows: C9.3.1.1. Word Size = 8 Bits C9.3.1.2. Baud Rate = 9600/14400 C9.3.1.3. Stop Bits = 1 C9.3.1.4. Parity = None C9.3.1.5. Telephone Numbers = (703) 767-6800 or 1-800-556-6725 C9.3.2. Depress < ENTER> twice until # appears. C9.3.3. Type password FTBELVOIR. C9.3.4. At the XYPLEX prompt, enter 131.74.1.13 . C9.3.5. Terminal will display information pertaining to the DLA NETWORK. Then type AFJM2PAS. C9.3.6. The next screen is for logging into the database. Type the login as: LOGIN 8299901. C9.3.7. Enter the password for the system. Type the password as: DISPENSE. C9.3.8. Open the database for system query. Type: OPEN LOGREGAL. C9.3.9. Enter password for database. Type the password as: HOORAY. C9.3.10. The system is now ready for information query/data retrieval. C9.4. ACCESSING THE SYSTEM USING HARDWARE OR AN OPEN SYSTEM NETWORK (SUCH AS DDN) Follow above instructions in section C9.3., above, starting with paragraph C9.3.5. C9.5. QUERY PROCEDURE C9.5.1. The Master LOGDRMS query procedure is identified by program number LQP. Interrogation of the LOGDRMS for retrieval and display of requested information requires a single query procedure. Type either: INCLUDE LQP or I LQP (I space LQP). C9.5.2. Response consists of a menu for viewer selection. Select the appropriate option. The screen will appear as follows: "WELCOME TO DoD LOGDRMS QUERY PROCEDURE.THIS PROGRAM PROVIDES VIEWING ACCESS ONLY. PLEASE SELECT AREA OF INTEREST." OPTION DESCRIPTION 1 ANSI ASC X12 (Include Logistics Qualifier Search) 2 (RESERVED) 3 DLSS 4 DoD LOGISTICS DATA ELEMENT 5 TERM/ACRONYM/ABBREVIATION 6 ANSI ASC X12 (OLD ROUTINE) 7 DLMS IMPLEMENTATION CONVENTIONS 8 DoD ACTIVITY ADDRESS 9 UN/EDIFACT MESSAGES 10 QUIT C9.6. OPTION 1-- ANSI ASC X12 QUERY PROCEDURE AND MENU SELECTION C9.6.1. Select option 1, ANSI ASC X12. The full screen application allows for a selection from the following 17 search parameters: SELECTION NUMBER NAME 1 TRANSACTION SET 2 SEGMENT 3 DATE ELEMENT 4 DATA CODE 5 TRANSACTION SET KEYWORD 6 SEGMENT KEYWORD 7 DATA ELEMENT KEYWORD 8 DATA CODE KEYWORD 9 ELEMENT (SEGMENT/POSITION) 10 CODE SOURCE 11 CODE SOURCE KEYWORD 12 ANSI STANDARD REFERENCE 13 PROJECT REFERENCE 14 DATA MAINTENANCE (DM) - SET 15 DATA MAINTENANCE (DM) - SEGMENT 16 DATA MAINTENANCE (DM) - DATA ELEMENT 17 LOGISTICS QUALIFIER C9.6.2. VERSION CONTROL. All queries contain provisions for entry of a six-position date (yymmdd) that identifies a specific ANSI ASC X12 version publication date. If this option is not exercised, the query automatically defaults to the latest published version and output displays reflect this information. C9.7. OPTION 2 -- DLMS QUERY PROCEDURE AND MENU SELECTION C9.7.1. Select option 7, DLMS IMPLEMENTATION CONVENTIONS. The full screen application allows for a selection from the same search parameters listed in paragraph C9.5.1., above. However, only selections 1 through 9 are applicable to this option. C9.7.2. Version Control. A need for version control, while not as critical to DLMS as to the ANSI ASC X12 Directory, is recognized. However, until decisions are made regarding the content, frequency, and criticality of changes, version 2.0 will be cited on all output displays as the latest published version. C9.8. OPTION 3 UN/EDIFACT MESSAGES Select option 9, UN/EDIFACT MESSAGES. The full screen application allows for a selection from the same search parameters listed in paragraph C9.5.1., above. However, only selections 1 through 9 are valid for this option. Also, EDIFACT Messages can be queried via selection number 1. C9.9. TERMINATION OF SESSION To terminate your on-line session, enter LOGOFF. Then enter QUIT to disconnect the XYPLEX server. Then use the disconnect procedures for your communication software package. AP1. APPENDIX 1 CLASS WORD NAME DEFINTIONS Proposals for new class words must be submitted through the appropriate CDAd or FDAd to the DoD DAd for approval. CLASS WORD NAME ABBREVIATION DESCRIPTION AND/OR DEFINITION STRUCTURE Amount AM A monetary value. (Includes average balance, deviation, factor, index, level, mean, mode, scale, and yield.) The generic element definition should begin: "The monetary unit representing..." The data element definition should begin: "The (modifiers) amount of..." Angle AN The rotational measurement between two lines and/or planes diverging from a common point and/or line. (Includes azimuth and heading.) The generic element definitions should begin: "The rotational measurement between..." The standard data element definition should begin: "The (modifiers) angle between (modifiers) for a..." Area AR The measurement of a surface expressed in unit squares (2-dimensional). The generic element definition should begin: "The area of..." The standard data element definition should begin: "The (modifiers) area of..." Code CD A combination of one or more numbers, letters, or special characters substituted for a specific meaning. Represents finite, predetermined values. (Must have a specific domain.) (Includes category and status.) The generic element definition should begin: "The specific value that represents and/or denotes a ..." The standard data element definition should begin: "The (modifiers) code that represents and/or denotes a..." Coordinate CN Designation of the location of a line or plane. (Includes latitude and longitude.) The generic element definition should begin: "The numeric designation identifying the location of..." The standard data element definition should begin: "The coordinate identifying the (modifiers) location of..." Date DT The designation of a specific 24-hour period of time. The generic element definition should begin: "The date of and/or when and/or on which a ..." The standard data element definition should begin: "The (modifiers) date of and/or when and/or which a ..." CLASS WORD NAME ABBREVIATION DESCRIPTION AND/OR DEFINITION STRUCTURE Dimension DM A measured linear distance (one-dimensional). (Includes altitude, depth, diameter, elevation, height, length, radius, vertex, and width.) The generic element definition should begin: "The one-dimensional linear measurement (length, width, height, radius, or elevation, etc.) of and/or from..." The standard data element definition should begin: "The dimension (length, width, height, radius, or elevation, etc.) of and/or from..." Identifier ID A combination of one or more numbers, letters, or special characters that designate a specific object/entity but that have no readily definable meaning. (Must have a general domain.) (Includes designator, key, number.) The generic element definition should begin: "The unique value, or set of characters, assigned to represent..." The standard data element definition should begin: "The (modifiers) identifier that represents..." Mass MS The measure of inertia of a body. The generic element definition should begin: "The measure of inertia of ..." The standard data element definition should begin: "The (modifiers) mass of ..." Name AM A designation of an object and/or entity expressed in a word or phrase. The generic element definition should begin: "The word(s) that represent(s)..." The standard data element definition should begin: "The name of..." Quantity QY A non-monetary numeric value. (Includes average, balance, count, deviation, factor, index, level, mean, mode, and scale.) The generic element definition should begin: "The non-monetary numeric unit representing the count or calculated unit or aggregated unit of..." The standard data element definition should begin: "The (modifiers) quantity of..." Rate RT A quantity or degree of something in relation to units of something else (e.g., miles per gallon) (includes acceleration, density, factor, flow, force, frequency, humidity, impedance, inductance, intensity, magnitude, moment, percent, power, pressure, resistance, scale, speed, tension, torque, velocity, viscosity, and voltage). The generic element definition should begin: "The relationship that represents (force, speed, or pay, etc.,) of..." The standard data element definition should begin: "The rate of..." CLASS WORD NAME ABBREVIATION DESCRIPTION AND/OR DEFINITION STRUCTURE Temperature TP The measure of heat in an object or space. The generic element definition should begin: "A number representing the heat of..." The standard data element definition should begin: "The temperature of..." Text TX An unformatted charter string, generally in the form of words. (Includes category and comments.) The generic element definition should begin: "The freeform narrative that (describes and/or defines)..." The standard data element definition should begin: "The text of..." Time TM A designation of a specified chronological point within a period. The generic element definition should begin: "The specific chronological point that designates the occurrence (in the past, present, or future) of..." The standard data element definition should begin: "The time of.." Volume VL Measurement of space occupied by a three-dimensional figure as measured in cubic units. The generic element definition should begin: "The three-dimensional cubic measurement of..." The standard data element definition should begin: "The volume of..." Weight WT The force with which an object is attracted toward the earth and/or another celestial body by gravitation. The generic element definition should begin: "The weight of..." The standard data element definition should begin: "The weight of..." AP2.1. APPENDIX 2 GENERIC AND DATA ELEMENT ATTRIBUTE DESCRIPTIONS The following alphabetical list of attributes reflects the contents of the DDRS at the date of publication of this Manual. These attributes will change over time through a configuration control process after recommendations are made to the DoD DAd. Refer to the DDRS for the most up-to-date versions of these attributes. This information is included due to its importance. The data elements listed in this Appendix have not been approved but are based on a data model and will be submitted as candidate standard data elements upon approval of the required prime words. AP2.1.1. Automated Information Software System Identifier AP2.1.1.1. Definition: Identification of the entire set of programs, procedures, and related documentation associated with a computer system. AP2.1.1.2. Domain Definition: A general domain comprised of the characters in the ASCII charter set. AP2.1.1.3. Length: 35 AP2.1.1.4. Type: Alpha-numeric AP2.1.1.5. Edit: Required attribute AP2.1.1.2. Automated Information Software System Name AP2.1.2.1. Definition: The name of a system that maintains (adds, modifies, and deletes) a standard data element. AP2.1.2.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.2.3. Length: 250 AP2.1.2.4. Type: Alpha-numeric AP2.1.2.5. Edit: Required attribute AP2.1.3. Generic Element Authority Reference Text AP2.1.3.1. Definition: Freeform text that describes the authority for and/or references supporting the existence of a particular generic element. AP2.1.3.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.3.3. Length: 999 AP2.1.3.4. Type: Alpha-numeric AP2.1.3.5. Edit: Optional attribute AP2.1.4. Generic Element Class Word Name AP2.1.4.1. Definition: The word that identifies a specific category of data (e.g., date, dimension, and code, etc.) that will be represented by data values of a standard data element associated with a particular generic element. AP2.1.4.2. Domain Definition: A specific domain comprised of the qualitative data values listed in Appendix 1, above, of this Manual. AP2.1.4.3. Length: 80 AP2.1.4.4. Type: Alphabetic AP2.1.4.5. Edit: Required attribute. The class word must be in class word table in an approved "A" status unless creating a new class word. Prohibit the use of class word by other users until approved for DoD use. AP2.1.5. Generic Element Class Word Position Identifier AP2.1.5.1. Definition: The number identifying the location of the class word in the generic name. AP2.1.5.2. Domain Definition: A general domain comprised of up to two of the following integer values: 1-99. AP2.1.5.3. Length: 2 AP2.1.5.4. Type: Integer AP2.1.5.5. Edit: Required attribute AP2.1.6. Generic Element Decimal Place Quantity AP2.1.6.1. Definition: The quantity of decimal places allowable for a given generic element value. AP2.1.6.2. Domain Definition: A general domain comprised the ASCII characters: 0-99. AP2.1.6.3. Length: 2 AP2.1.6.4. Type: Numeric AP2.1.6.5. Edit: Required attribute for generic element only if the generic element type name is fixed-point. This attribute is displayed at the data element level and cannot be changed. AP2.1.7. Generic Element Definition Text AP2.1.7.1. Definition: Freeform text that represents the definition of a given generic element. AP2.1.7.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.7.3. Length: 999 AP2.1.7.4. Type: Alpha-numeric AP2.1.7.5. Edit: Required attribute AP2.1.8. Generic Element Domain Definition Text AP2.1.8.1. Definition: Freeform text that describes the overall meaning or general characteristics of the domain of a particular generic element. AP2.1.8.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.8.3. Length: 999 AP2.1.8.4. Type: Alpha-numeric AP2.1.8.5. Edit: Required attribute AP2.1.9. Generic Element Domain Value Definition Text AP2.1.9.1. Definition: Freeform text describes the meaning of a domain value of a given generic element. AP2.1.9.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.9.3. Length: 999 AP2.1.9.4. Type: Alpha-numeric AP2.1.9.5. Edit: Required attribute if there are no low-range or high-range identifiers. AP2.1.10. Generic Element Domain Value Identifier AP2.1.10.1. Definition: The unique identifier that represents a particular value within the domain of a specific generic element. AP2.1.10.2. Domain Definition: A general domain comprised of the following ASCII characters: A-Z, 0-9, hyphen (-), point (.), slash (/), underscore (_), and ampersand (&). AP2.1.10.3. Length: 35 AP2.1.10.4. Type: Alpha-numeric AP2.1.10.5. Edit: Required attribute for quantitative data if there are no low-range and high-range identifiers or no source list text. AP2.1.11. Generic Element High-Range Identifier AP2.1.11.1. Definition: The unique identifier that denotes the highest allowable value permitted in the domain range of a given generic element. AP2.1.11.2. Domain Definition: A general domain comprised of all real numbers. AP2.1.11.3. Length: 15 AP2.1.11.4. Type: Numeric AP2.1.11.5. Edit: Required attribute if there are no domain value identifiers or source list text. If there is a high-range identifier, it must not be greater than the maximum character count quantity. AP2.1.12. Generic Element Low-Range Identifier AP2.1.12.1. Definition: The unique identifier that denotes the lowest allowable value permitted in the domain range of a given generic element. AP2.1.12.2. Domain Definition: A general domain comprised of the following ASCII characters: 0-9, point (.), and minus (-). AP2.1.12.3. Length: 15 AP2.1.12.4. Type: Numeric AP2.1.12.5. Edit: Required attribute if there are no domain value identifiers or source list text. AP2.1.13. Generic Element Maximum Character Count Quantity AP2.1.13.1. Definition: The maximum quantity of characters that can be stored for a domain value associated with a given generic element. AP2.1.13.2. Domain Definition: A specific domain of quantitative data values ranging from 0001-9999. AP2.1.13.3. Length: 4 AP2.1.13.4. Type: Numeric AP2.1.13.5. Edit: Required attribute AP2.1.14. Generic Element Name AP2.1.14.1. Definition: The long standard name of a specific type of data element (generic element) that describes and identifies a generic structure and domain. A generic element has no organizational or application context. The structured name format comprises zero to n modifiers and one class word. The general name format comprises: modifier and/or modifier and/or class word. AP2.1.14.2. Domain Definition: A general domain comprised of the following ASCII characters: A-Z, hyphen (-), and space. AP2.1.14.3. Length: 80 AP2.1.14.4. Type: Alpha-numeric AP2.1.14.5. Edit: Required attribute. The class word must be in the class word table unless the user is creating a new class word. AP2.1.15. Generic Element Security Classification Name AP2.1.15.1. Definition: A code that defines the security classification of the existence of a specific generic element or its metadata. AP2.1.15.2. Domain Definition: A specific domain comprised of the following qualitative data values: NATO (North Atlantic Treaty Organization) Top Secret Atomal NATO Top Secret Top Secret NATO Secret Atomal NATO Secret Secret Secret Restricted NATO Confidential Atomal NATO Confidential Confidential Confidential Restricted NATO Restricted For Official Use Only Unclassified Sensitive Unclassified AP2.1.15.3. Length: 25 AP2.1.15.4. Type: Alphabetic AP2.1.15.5. Edit: Required attribute. The default is unclassified (may be changed). AP2.1.16. Generic Element Type Name AP2.1.16.1. Definition: The name of the data type associated with a specific generic element. AP2.1.16.2. Domain Definition: A specific domain comprised of the following qualitative data values: bit-string, integer, character string, fixed-point, and floating-point. AP2.1.16.3. Length: 16 AP2.1.16.4. Type: Alpha-numeric AP2.1.16.5. Edit: Required attribute AP2.1.17. Information Element Justification Category Name AP2.1.17.1. Definition: The positional justification of data values within a storage field. AP2.1.17.2. Domain Definition: A specific domain comprised of the following qualitative data values: left and right. AP2.1.17.3. Length: 5 AP2.1.17.4. Type: Alphabetic AP2.1.17.5. Edit: Required attribute for a generic element and display only for a data element. AP2.1.18. Information Element Standardization Authority Code AP2.1.18.1. Definition: The branch of Service, Government, or international organization that approved the element. AP2.1.18.2. Domain Definition: A specific domain comprised of the following qualitative data values: ANSI American National Standards Institute DoD Department of Defense FIPS Federal Information Processing Standards ISO International Organization for Standardization NATO North Atlantic Treaty Organization AP2.1.18.3. Length: 4 AP2.1.18.4. Type: Alphabetic AP2.1.18.5. Edit: Optional attribute AP2.1.19. Information Qualitative Data Value Accuracy Number Percent Rate AP2.1.19.1. Definition: An indicator of how accurate a qualitative data value must be. AP2.1.19.2. Domain Definition: A specific domain comprised of qualitative data values (0-9) ranging from 1 to 100. AP2.1.19.3. Length: 3 AP2.1.19.4. Type: Numeric AP2.1.19.5. Edit: Required attribute if data is qualitative. AP2.1.20. Information Quantitative Data Accuracy Code AP2.1.20.1. Definition: A character string indicating how accurate a quantitative data value must be. AP2.1.20.2. Domain Definition: A specific domain comprised of the following: 1 nearest million 2 nearest 100,000 3 nearest 10,000 4 nearest 1,000 5 nearest 100 6 nearest 10 7 nearest 1 8 nearest .1 9 nearest .01 10 nearest .001 11 nearest .0001 12 nearest .00001 99 none AP2.1.20.3. Length: 2 AP2.1.20.4. Type: Numeric AP2.1.20.5. Edit: Required attribute if data is quantitative. AP2.1.21. Prime Word Name AP2.1.21.1. Definition: The name of the primary object (i.e., person, place, thing, or concept) of interest that a given data element describes. AP2.1.21.2. Domain Definition: A general domain comprised the ASCII characters A-Z and hyphen (-). AP2.1.21.3. Length: 170 AP2.1.21.4. Type: Alphabetic AP2.1.21.5. Edit: Required attribute. The prime word name is a variable length field comprising zero to n modifiers and a prime word. AP2.1.22. Prime Word Name Definition Text AP2.1.22.1. Definition: A narrative describing the context of a principal term that has a precise meaning as it relates to a data entity standard. AP2.1.22.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.22.3. Length: 999 AP2.1.22.4. Type: Alpha-numeric AP2.1.22.5. Edit: Required attribute AP2.1.23. Prime Word Steward Name AP2.1.23.1. Definition: The designated proponent for each prime word name derived from an information model. AP2.1.23.2. Domain Definition: A general domain, e.g.: USD(A) USD(P) ASD(SOLIC) ASD(C3I) USD(C) ASD(FMP) ASD(HA) ASD(LA) ASD(RA) IG, DoD GC, DoD AP2.1.23.3. Length: 10 AP2.1.23.4. Type: Alpha-numeric AP2.1.23.5. Edit: Required attribute AP2.1.24. Prime Word Using Proponent Model Name AP2.1.24.1. Definition: The name of the proponent for which the prime word name is contained in an information model. AP2.1.24.2. Domain Definition: A general domain comprised of the ASCII character set. AP2.1.24.3. Length: 10 AP2.1.24.4. Type: Alpha-numeric AP2.1.24.5. Edit: Optional attribute AP2.1.25. Word Modifier Name AP2.1.25.1. Definition: A character string that further describes a characteristic of an object, a relationship between objects or the object itself. AP2.1.25.2. Domain Definition: A general domain comprised of the ASCII characters: A-Z, hyphen (-), and underscore (_). AP2.1.25.3. Length: 170 AP2.1.25.4. Type: Alpha-numeric AP2.1.25.5. Edit: Optional attribute. Cannot be a class word. AP2.1.26. Prime Word Position Identifier AP2.1.26.1. Definition: The number identifying the location of the prime word name in the data element name. AP2.1.26.2. Domain Definition: A general domain comprised of integer values 01-99. AP2.1.26.3. Length: 2 AP2.1.26.4. Type: Numeric AP2.1.26.5. Edit: Required attribute AP2.1.27. Standard Data Element Access Name AP2.1.27.1. Definition: An abbreviated name representing a specific data element. An access name is used to reference a data element in a database and must conform to the syntactical requirements of the database management system (DBMS) or programming language of the application in which a data element is used. AP2.1.27.2. Domain Definition: A general domain comprised of the following ASCII characters: A-Z, 0-9, hyphen (-), underscore (_), and period (.). AP2.1.27.3. Length: 30 AP2.1.27.4. Type: Alpha-numeric AP2.1.27.5. Edit: Required at the time a data element is identified for use in an automated system. AP2.1.28. Standard Data Element Authority Reference Text AP2.1.28.1. Definition: Freeform text that describes the authority for and/or references supporting the existence of a particular data element. AP2.1.28.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.28.3. Length: 999 AP2.1.28.4. Type: Alpha-numeric AP2.1.28.5. Edit: Optional attribute AP2.1.29. Standard Data Element Comment Text AP2.1.29.1. Definition: An administrative narrative regarding a generic element, standard data element, or nonstandard data element. AP2.1.29.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.29.3. Length: 999 AP2.1.29.4. Type: Alpha-numeric AP2.1.29.5. Edit: Optional attribute AP2.1.30. Standard Data Element Component Code AP2.1.30.1. Definition: A code that denotes the DoD organization that uses a given data element within its systems. AP2.1.30.2. Domain Definition: A specific domain comprised of data values identifying the DoD Components. For example: DCAA Defense Contract Audit Agency DFAS Defense Finance and Accounting Service DIA Defense Intelligence Agency DIS Defense Investigative Agency DISA Defense Information Systems Agency DLA Defense Logistics Agency DLSA Defense Legal Services Agency DMA Defense Mapping Agency DNA Defense Nuclear Agency DRPA Defense Research Projects Agency DSAA Defense Security Assistance Agency NSA National Security Agency/Central Security Service OSD Office of the Secretary of Defense SDIO Strategic Defense Initiative Organization USAF United States Air Force USMC United States Marine Corps The above is a partial list of domain data values; the complete list of domain data values is available in the Defense Data Dictionary System (DDDS). AP2.1.30.3. Length: 15 AP2.1.30.4. Type: Alphabetic AP2.1.30.5. Edit: Optional attribute AP2.1.31. Standard Data Element Data Value Source List Text AP2.1.31.1. Definition: The source in which a lengthy list of data values is enumerated. AP2.1.31.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.31.3. Length: 999 AP2.1.31.4. Type: Alpha-numeric AP2.1.31.5. Edit: Optional attribute. For qualitative data if you have source list text, you will not have domain value identifiers. AP2.1.32. Standard Data Element Decimal Place Count Quantity AP2.1.32.1. Definition: The quantity of decimal places allowable for a given data element. AP2.1.32.2. Domain Definition: A general domain comprised of the ASCII characters AP2.1.32.3. Length,: 2 AP2.1.32.4. Type: Numeric AP2.1.32.5. Edit: Required attribute for generic element if element type name is fixed-point. This attribute is displayed at the data element level and cannot be changed. If there is a decimal place count quantity at the generic element level and the element type name is other than fixed-point, the system will display the decimal place count quantity, and it can be changed to be equal to or less than the decimal place count quantity at the generic element level. AP2.1.33. Standard Data Element Definition Text AP2.1.33.1. Definition: Freeform text that represents the definition of a given data element. AP2.1.33.2. Domain Definition: A general domain comprised of the characters in the ASCII character set. AP2.1.33.3. Length: 999 AP2.1.33.4. Type: Alpha-numeric AP2.1.33.5. Edit: Required attribute AP2.1.34. Standard Data Element Domain Definition Text AP2.1.34.1. Definition: Freeform text that describes the overall meaning or generic characteristics of the domain of a