|The International Organization
|The United Nations Economic
Commission for Europe
|EDIFACT Application Level Syntax Rules (ISO 9735)|
|Versions 1, 2, 3 and 4 - The differences in context|
The EDIFACT Application Level Syntax Rules (ISO 9735) Level represent the rules at the application level for the structuring of data in the interchange of electronic messages in an open environment, based on the requirements of either batch or interactive processing. In particular these syntax rules serve to support the global UN/EDIFACT standard for EDI. The syntax rules include the definition of the service envelopes, service messages (latest version) and syntax constructs such as the default separator characters and rules for inclusion and exclusion.
To date, 4 versions of the syntax have been released. The latest, Version 4, was approved in October 1998.
|First published in 1988, this particular version no longer supports recent releases of the UN/EDIFACT directories. The directory version/release has changed from a numeric notation (eg. 91.2) to an alphanumeric format (eg. D.99B). In the UNG (Functional group header) and the UNH (Message header) service segments the corresponding data elements (0052/0054) are defined as being numeric.|
|Published in 1990, the syntax rules specified in Version 2 remained unchanged from Version 1 with the exception that the alphanumeric version/release format is supported and the status of the message release number (0054) and controlling agency (0051) were changed from conditional to mandatory.|
|Version 3 is represented by Version 2 plus Amendment 1, published in 1992. Amendment 1 extended the supported character sets from character set A (ISO 646 with the exception of lower case letters and certain graphic characters) and B (ISO 646 with the exception of certain graphic characters) to the character sets C through F (covering Latin, Cyrillic and Greek alphabets).|
|Version 4 represents a significant revision to the syntax rules and supersedes the earlier publications. It is not fully upward compatible with Version 3 (eg. a single set of default service characters are defined in Version 4, where the level A and B character sets in earlier versions, each specified separate service characters).
While messages specified in the D.99A and earlier UN/EDIFACT Directories may use Versions 2, 3 and 4 of the syntax rules, it should be noted that messages specified in the D.99B and later UN/EDIFACT Directories that use features specific to Version 4 (eg. repeating composite data elements), these messages must use Version 4 of the syntax rules.
The Version 4 syntax rules comprise 9 individual parts:
Part 1 is a re-draft of corresponding sections in the previous version of syntax rules. It consists of the rules common to all parts of Version 4 of the syntax, and includes the definitions and service directories for all parts. The basic syntax rules specified in this part remain unchanged from Version 3, with the exception that the coverage of character repertoires has been extended, and two new techniques have been introduced (the provision for 'dependency notes' and the introduction of a service repetition character, to support the capability of permitting multiple occurrences (repeats) of stand-alone and/or composite data elements). Both of these techniques are used in other parts of Version 4 of the syntax rules, and are available for specification in UN/EDIFACT messages that utilise these rules.
In addition, enhancements have been made to the batch interchange; group; and message header segments (UNB; UNG; and UNH).
Character repertoires: Because of the widening use of ISO 9735, it has become necessary to extend its coverage to include all character repertoires covered by ISO 8859, Parts 1-9 (Information processing - 8-Bit single - byte coded graphic character sets); the code extension techniques covered by ISO 2022 (with certain restrictions on its use within an interchange); and partial use of the techniques covered by ISO/IEC 10646-1.
Dependency notes: These provide a formal notation to express relationships within UN/EDIFACT message, segment and composite data element specifications.
Repeating data elements: The specification of multiple occurrences of a message within a group or within an interchange; a group within an interchange; and a segment group and/or a segment within a message, which existed in the previous version of the syntax rules, has been extended in the current version. The additional capability for the specification of multiple occurrences of a stand-alone data element and/or of a composite data element within a segment has been introduced.
UNB - Interchange header segment: This segment has been enhanced to permit the identification of the service code list directory version number; identification of the character encoding scheme; and internal sub-identification of the sender and recipient. In addition, to conform to year 2000 requirements, the date format in this segment has been extended.
UNG - Group header segment: This segment has been re-named and its function changed to permit one or more message types and/or packages to be contained in the group. As a result, certain data elements, which are now redundant, have been marked for deletion. In addition, to conform to year 2000 requirements, the date format in this segment has been extended.
UNH - Message header segment: This segment has been enhanced to permit the identification of a message subset, of a related message implementation guideline, and of a related scenario.
UGH/UGT - Anti-collision segment group: An addition has been made in this version of the syntax rules to permit the prevention of segment collision, by use of the UGH/UGT segment group. This technique may be used in a UN/EDIFACT message specification when it is not otherwise possible to ensure unambiguous identification of each message segment upon receipt.
Part 2 is specific to batch EDI and is a re-draft of corresponding sections in the previous version of the syntax rules. It is identical, except for minor changes to terminology, and for clarification of the use of segment groups.
Part 3 is a new part, which has been added to the syntax rules. It provides for the exchange of UN/EDIFACT messages in an interactive (conversational) EDI environment. Interactive EDI (I-EDI) is characterised by the following:
These characteristics differentiate I-EDI from batch EDI (as specified in Part 2). For consistency and in order to simplify the implementation of the syntax rules for those users who wish to utilise both batch and interactive processing, this part of the rules has been aligned as far as possible with the batch syntax rules.
Part 4 of the syntax rules provides the capability for the automatic preparation of the CONTRL message in response to a received interchange, group, message or package:
In the case of rejection, the message lists any syntactical errors or unsupported functions encountered. In addition to the above, the message may be used to indicate only the receipt of an interchange.
It is based upon a similar CONTRL service message developed and published as separate document for use with earlier versions of the syntax rules.
Part 5 is a new part, which has been added to the syntax rules. It provides an optional capability of securing batch UN/EDIFACT structures. It provides a method to address message/package level, group level, and interchange level security for authenticity, integrity and non-repudiation of origin, in accordance with established security mechanisms.
Part 6 is a new part, which has been added to the syntax rules. It provides an optional capability of securing batch UN/EDIFACT structures, ie. messages, packages, groups or interchanges, by means of a secure authentication and acknowledgement message, AUTACK.
Part 7 is a new part, which has been added to the syntax rules. It provides an optional capability of applying confidentiality to a batch UN/EDIFACT structures. It provides a method to address message/package level, group level and interchange level security for confidentiality in accordance with established security mechanisms.
Part 8 is a new part, which has been added to the syntax rules. It provides an optional capability of associating a package of data, which contains an object bounded by EDIFACT service segments as envelopes. The option permits the transfer within an UN/EDIFACT interchange of data which can be created by other applications, such as STEP (Standard for The Exchange of Product model data), CAD (Computer Aided Design), etc., and which cannot be carried by means of an UN/EDIFACT message.
Part 9 is a new part, which has been added to the syntax rules. It provides an optional capability of managing security keys and certificates using the KEYMAN message.