UNITED NATIONS E Economic and Social Council Distr. RESTRICTED TRADE/CEFACT/GE.1/1997/4 11 July 1997 ENGLISH ONLY ECONOMIC COMMISSION FOR EUROPE COMMITTEE FOR TRADE, INDUSTRY AND ENTERPRISE DEVELOPMENT Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport (Item 3 of the provisional agenda of the Meeting of Experts on Data Elements and Automatic Data Interchange (GE.1) (fifty-sixth session, 17-18 September 1997) UN/EDIFACT Report to GE.1 from the Message Design Rules Group * * * Submitted by the Message Design Rules Group * The group of experts is expected to: approve the recommendations made in this document and note the rest of the document as being for information and further discussion. The present document is reproduced in the form in which it was received by the secretariat. 1997-09-15 UN/EDIFACT Report to GE.1 from the Message Design Rules Group SOURCE: MDR Group Chairman STATUS: Chairman's Report ACTION: FOR APPROVAL, September 1997 GE.1 Meeting MESSAGE DESIGN RULES GROUP REPORT TO GE.1 1. INTRODUCTION During the fiftieth session of the Meeting of Experts (UN/ECE/TRADE/WP.4/GE.1) on Data Elements and Automatic Data Interchange the UN/EDIFACT Message Design Rules Group submitted its first formal report to the GE.1 (R.1083). R.1083, approved at that session, defined the tasking for the MDR Group as: (1) the review of the documents set forth in the Terms of Reference, and additional comments received, thereto (2) provide a draft recommended Revision 3 the existing Message Design Guidelines (R.840/Rev.2) including those comments received that remove inconsistencies to that document, (3) development of a new MDR draft document that includes new concepts and procedures once general consensus has been reached on these items through procedures developed by the MDR group, and (4) development of comprehensive procedures to maintain newly developed MDR versions. TRADE/WP.4/R.1083 set forth the organizational structure and working procedures for the two MDR Group teams: Draft and Edit Team (DET) and Quality Assurance Team (QAT) as well as the time scales for accomplishment of the above listed tasking. TRADE/WP.4/R.1083 also introduced a proposed balloting process for new MDR version development; procedures for the submission of MDR comments; MDR work items and topics as well as a Statement of Purpose and Scope for the MDRs. 2. EXECUTIVE SUMMARY At the last meeting of GE.1 (Fifty-fifth session, 19-20 March, 1997) the following course of action was recommended by the MDR Group and accepted by the meeting: To finalise the Message Design Rules for Batch EDI covering Version 3 of the Syntax at the Singapore JRT, and to submit these by June 15, 1997 for approval at the September 1997, session of GE.1. At that session delegations would be requested to either approve or to reject this document without further modification. The present Message Design Rules Group would be disbanded following this action Furthermore, subject to GE.1 approval, the implementation strategy would be determined in consultation with the Chairs of Regional Technical Assessment Groups. Outstanding submissions and comments on TRADE/WP.4/R.840/Rev.3. were evaluated by the MDR Group at the Singapore JRT and were addressed in consultation with the Joint Technical Assessment Group (JTAG) Co-Chairs. Resulting from this review process is the final version of Message Design Rules for Batch EDI, TRADE/WP.4/R.840/Rev.4. The MDR Group seeks the approval of GE.1 to this document. Subject to approval of this document by GE.1, it is recommended that the date for the implementation and adoption by the JRT process of TRADE/WP.4/R.840/Rev.4 immediately follow the April 1998 JRT meeting. In accordance with this direction a draft Implementation Plan has been tabled at this session of GE.1 as a Conference Room Paper. This document represents the combined position of the MDR Group and the Chairs of the regional Technical Assessment Groups. It will presented for final adoption at the Anaheim JRT. GE.1 should note that R.840/Rev.4 will not be applied retrospectively to the existing UN/EDIFACT Directories, but shall form the basis for the technical assessment for future maintenance of the Directories. 3. TRADE/WP.4/R.840 REVISION 4 The following sub-sections explain the background and philosophy behind the decisions which resulted in TRADE/WP.4/R.840/Rev.4. 3.1 Segment and composite design philosophy In order to develop a set of consistent rules that distinguish between when to design a segment and when to design a composite data element, the UN/EDIFACT directories were first analysed to determine the approach used for the design of existing segment and composite data element structures. In these directories there are many examples of simple, concise structures and many examples of complex, hybrid structures which highlighted that the design principles lacked precision and consistency. Further reference sources were examined and included documents on database design, object oriented methodology and normalisation practices. This led to the following conclusions : The most important aspect of message design is the provision of definitions for the meaning of the data and the extraction of a name directly from these definitions to label the data. A message represents the structure for the data of a defined information flow between two parties. Segments and segment groups are one of the building blocks of messages. A segment and/or segment group represents a functionally related set of data elements whose characteristics define a single distinct concept (e.g. a party, a place, a product, a service, a document, etc.). For pragmatic reasons, UN/EDIFACT has recommended that the approach to segment design be generic rather than specific. The design of a generic segment provides a means for the segment to be used across a wide range of applications by having each specific instance of usage specified in the qualifier data element. This qualifier data element is the first data element in the segment and enables the usage context of the segment to be defined during message implementation. For reasons of consistency, the segment design rules now require that all segments be specified with a qualifier data element. This qualifier data element can be specified with a status of mandatory or conditional since, within a segment group, a segment may be qualified by another segment at a higher level, hence rendering further qualification unnecessary. A segment structure consists of a qualifier data element and one or more additional data elements. All data elements within the segment must directly relate to the concept represented by the segment. In the case where a data element represents a characteristic that is only partially related to the concept, a separate segment is required for this data element. This rationalisation process, when carried out correctly, will not permit the same characteristic to be assigned more than once to the same concept. This means that a segment structure cannot have the same data element specified more than once within the segment structure. The only exception to this rule is the use of a qualified composite data element, since its qualifier data element may be used to assign different characteristics to the qualified composite data element. As a practical limit, it is suggested that the same qualified composite data element should not be specified more than five times within a segment. One of the purposes of the segment definition is to describe the concept that is represented at a certain level of abstraction. The level of abstraction is normally dependent upon the information model which is used as the basis for developing a UN/EDIFACT message. Within the UN/EDIFACT directories there are segments with a broad level of abstraction (e.g. ATT - Attribute) and segments with narrower levels of abstraction (e.g. DOC - Document/ Message Details). When determining whether a segment duplicates or overlaps the functionality of another segment, it is important to compare only segments that have been developed at the same level of abstraction. It is not valid, for example, to compare the DOC segment with the ATT segment since the latter is so broad in terms of its level of abstraction that it could encompass all segments at a narrower level. For pragmatic reasons, it is recommended that a limit is established regarding the maximum broadest level of abstraction for segments. Since the object class term (see Annex B) represents the dominant area of interest it also can be used to determine the level of abstraction. As a guideline, therefore, the maximum broadest level of abstraction is reached when the object class term is a word that equates to one of the words taken from the list of representation terms (e.g. quantity, rate, amount). Note that the ATT segment is broader than this maximum limit, but there is no intention to apply these principles retroactively. Two message sub-structures can be identified within UN/EDIFACT to represent a single distinct concept. The first sub-structure is the stand-alone segment, which identifies a single concept whose characteristics are entirely defined by the data elements specified in the UN/EDIFACT directories for that segment. The second sub-structure is the segment group, which can identify a single concept whose characteristics are entirely defined by the data elements specified in the UN/EDIFACT directories for those segments within the segment group. Within UN/EDIFACT, a segment group may also be used to define a dependency between one segment and another or to define a hierarchical relationship between segments. In these instances, the segment group represents the broad concept and the segment(s) within the segment group and the subordinate segment group(s) represent narrower concepts. Each narrower concept inherits all of the characteristics of the broad concept plus at least one additional distinguishing characteristic, which serves to differentiate the narrower concepts at the same level of abstraction. A trigger segment is the first segment in a segment group and enables the usage context of the segment group to be defined during message implementation. A data element represents an elementary unit of information. For pragmatic reasons, UN/EDIFACT provides two means of expressing a data element to define the specific characteristics of a segment; the simple data element and the composite data element. The simple data element identifies a single unit of data whose characteristics are entirely defined by the specification of the data element within the UN/EDIFACT directories. The composite data element identifies a single unit of data whose characteristics are not entirely specified within the UN/EDIFACT directories (i.e. non-UN/EDIFACT code lists) or whose representation characteristics can be provided in two different forms (i.e. coded and/or non-coded) or whose characteristics are defined by an aggregate of two data elements (i.e. a qualifier data element and a simple data element). The rules contained herein for the design of data elements are consistent with the design philosophy of providing only two data element structures. In order to align current design practices with this philosophy, the design of a composite data element structure is limited to one of the eight formats specified in these rules. The design rule which restricted the specification of a textual data element to a maximum length of an..17, an..35 or an..70 has been removed. This means that message designers can specify the maximum length of a data element that is appropriate for the data element (e.g. an..128). A maximum length must be specified for each data element. 3.2 Naming and defining Following considerable analysis of ISO 11179 and in particular of ISO/IEC IS 11179-5 (Naming and identification principles for data elements), the adoption of section 6 (and informative Annex A) as part of the UN/EDIFACT message design rules is recommended. In order to apply these principles fully in the UN/EDIFACT environment, the following adaptations were required: The principles were extended to cover not only the naming of simple data elements but also to cover the naming of composite data elements and segments. The use of qualifier terms in a data element name was modified to align this with the use of qualifier data elements in UN/EDIFACT. The existing UN/EDIFACT term ',coded' at end of the name of a simple data element has been replaced by the representation term of 'code' in accordance with ISO 11179-5. There is recognition that the term 'number' has been used inconsistently within many data directories, leading to ambiguity. Sometimes 'number' refers to an arithmetic value. In other cases, 'number' is used to refer to a value from an identification scheme (e.g. an insurance policy) to distinguish one instance from another. In order to differentiate between these two types of usage, the representation term of 'identifier' has been introduced and the definition of 'number' has been restricted to an arithmetic value. Since business terms frequently form part of the name of a code value, the ISO 11179-5 naming convention is not considered appropriate for the structuring of names for code values. It is recommended that the term 'definition' is used throughout the UN/EDIFACT directories in place of terms segment 'function', data element 'description', code value 'description', etc. This recommendation is in line with ISO 11179. 3.3 Summary In order to differentiate between a segment and a composite data element, this document explains what each construct should represent. A standard naming convention has also been introduced to enable the names of data elements and segments to be constructed in a consistent manner. This has required the introduction of terminology which is not present in R.840/Rev.2. Furthermore, it should be recognised that the Message Design Rules is a document intended for the message designer and the Technical Assessment Groups and is not aimed at being a tutorial or guideline for the novice. The adoption of a more precise, consistent and coherent set of design principles will ensure that the data directories are of the highest standard, thus meeting the growing requirements of the UN/EDIFACT user community. 4. MEMBERSHIP STRUCTURE The Message Design Guidelines Group (MDR Group) consisted of an Executive Committee and two teams, the Draft and Edit Team (DET) and the Quality Assurance Team (QAT), respectively. The Executive Committee was the overall control body for MDR Group efforts. The DET was responsible for managing the work program as well as the review/disposition of all inputs received by the MDR Group. This group drafted and edited all inputs proposed to the MDR Group. These drafts were passed to the QAT as the initial forum to examine critically the proposed changes in accordance with agreed quality review processes. The QAT also participated in the resolution of open issues identified by the DET and contributed to the overall processing of MDR work items. The principle task of the QAT was to ensure the delivery of a quality product. Message Design Guidelines Group Executive Committee: Chairman Capt. Robert C. Hurd, USN (Ret.) - USA Vice Chairman Mr. David Dobbing - Australia Vice Chairman Mr. John Hooker - UK Secretariat/Secretary Mr. Peter Wilson - UK Message Design Guidelines Group Draft and Edit Team (DET): Chairman Mr. David Dobbing - Australia Members Mr. Klaus-Dieter Naujok - PAEB Mr. Mike Conroy - France Mr. Peter Wilson - UK Message Design Guidelines Group Quality Assurance Team (QAT): Chairman Mr. John Hooker - UK Members * Membership of the QAT is drawn from each JRT Joint Message Development Group and Special Interest Group represented at the JRT (One designated member from each group). ------------------------