ISO/TS 20625:2002

TECHNICAL ISO/TS
SPECIFICATION 20625
First edition
2002-05-01
Electronic data interchange for
administration, commerce and transport
(EDIFACT) — Rules for generation of XML
scheme files (XSD) on the basis of
EDI(FACT) implementation guidelines
Échange de données informatisé pour l'administration, le commerce et le
transport (EDIFACT) — Règles pour la génération de fichiers de schéma
XML (XSD) basés sur les guides de mise en œuvre d'EDI(FACT)

Reference number
©
ISO 2002
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2002
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2002 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of technical committees is to prepare International Standards. Draft International Standards adopted
by the technical committees are circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a technical
committee may decide to publish other types of normative document:
 an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in an
ISO working group and is accepted for publication if it is approved by more than 50 % of the members of the
parent committee casting a vote;
 an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting a
vote.
An ISO/PAS or ISO/TS is reviewed after three years with a view to deciding whether it should be confirmed for a
further three years, revised to become an International Standard, or withdrawn. In the case of a confirmed ISO/PAS
or ISO/TS, it is reviewed again after six years at which time it has to be either transposed into an International
Standard or withdrawn.
Attention is drawn to the possibility that some of the elements of this Technical Specification may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 20625 was prepared by DIN (as DIN 16557-5) and was adopted, under a special “fast-track procedure”, by
Technical Committee ISO/TC 154, Processes, data elements and documents in commerce, industry and
administration, in parallel with its approval by the ISO member bodies.
Annex A of this Technical Specification is for information only.

Introduction
Traditional EDI standards provide a syntax for the implementation of data content in various business processes
through the use of data elements, segments and message types. Initially XML provides simply another syntax,
which, if used to re-invent EDI, leads to huge new costs thus preventing any achievement of the initial goal - to get
small and medium sized enterprises (SME) involved in electronic business processes.
This standard describes how existing EDI know-how can be applied to the XML syntax. XML users would therefore
be able to easily use EDI data from existing applications in a consistent manner.
EDIFACT Message Implementation Guidelines (MIGs) describe the implementation of standardised EDIFACT
message types within a business process. Therefore MIGs are the suitable source for the derivation of XML
schemas. This standard specifies the process of translation.

iv © ISO 2002 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 20625:2002(E)

Electronic data interchange for administration, commerce and
transport (EDIFACT) — Rules for generation of XML scheme
files (XSD) on the basis of EDI(FACT) implementation
guidelines
1 Scope
This standard describes the rules for the derivation of XML schemas from EDI MIGs providing a sound
method of representing semantic facts.
This standard describes how to derive XML from UN/EDIFACT MIGs. In principle, the rules are equally
applicable to other EDI standards.
This standard does not apply to DTDs.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this
Technical Specification. At the time of publication, the editions indicated were valid. All standards are subject
to revision, and parties to agreements based on this Technical Specification are encouraged to investigate
the possibility of applying the most recent editions of the standards indicated below. Members of IEC and
ISO maintain registers of currently valid International Standards.
ISO 8601:2000-12, Data elements and interchange formats — Information interchange — Representation of
dates and times.
ISO 9735-1:1998-10, Electronic data interchange for administration, commerce and transport (EDIFACT) –
Application level syntax rules (Syntax version number 4, Syntax release number: 1) – Part 1: Syntax rules
common to all parts.
3 Terms, symbols and abbreviations
For the purpose of this standard the following terms, symbols and abbreviations apply.
3.1
BSR
Basic Semantics Register
3.2
BSU
Basic Semantic Unit
3.3
DTD
Document Type Definition
3.4
EDI
Electronic Data Interchange
3.5
EDIFACT
Electronic Data Interchange for Administration, Commerce and Transport
3.6
ELEMENT
Syntactic building block containing data and/or attributes.
3.7
HTML
Hyper Text Mark-up Language
3.8
MIG
Message Implementation Guideline
3.9
NAME
A name in the context of XML starts with a letter or a permitted special character followed by letters,
numbers, hyphens, underlines, colons or points. All those are known as name tag. Names starting with "xml"
or with a character string which fits to (('X'|'x') ('M'|'m') ('L'|'l') are reserved for XML standardisation.
3.10
SGML
Standard Generalised Mark-up Language
3.11
Tag
Formatting instruction or semantic markup
3.12
Template
Predefined reference pattern compared with the complete entity to be recognised, or one of its parts.
3.13
XLL
Extensible Link Language
2 © ISO 2002 – All rights reserved

3.14
XML
Extensible Mark-up Language
3.15
XSD
Extensible Schema Definition
3.16
XSL
Extensible Stylesheet Language
3.17
W3C
World Wide Web Consortium
4 Typical contents of Message Implementation Guidelines
4.1 Level: MIG
a) Identification of MIG
b) Identification of the supporting EDIFACT directory
c) Identification of the message type and, if necessary, the industry subsets
d) Additional text
4.2 Level: Message Type
a) Structure of the message type (segments and segment groups) and indication of their portions used
b) Status (standard versus application) of the segments and segment groups in use
c) Context related names and descriptions of the segments and segment groups
d) Examples
e) Dependencies between segments and segment groups
f) Additional text, comments on message type level
4.3 Level: Segments and Composite Data Elements
a) Structure of the segments and composite data elements and indication of their portions used
b) Status (standard versus application) of the data elements and composite data elements
c) Dependencies between data elements and composite data elements within a segment and within the
message type
d) Context related names and descriptions
e) Examples
f) Additional text, comments
4.4 Level: Data element
a) Characteristics of EDI data elements (type, length) and their usage restrictions based upon MIG and
context related implementation
b) Context related names and descriptions of data elements and, if necessary, unique tags and
descriptions, e. g. derived from data repositories such as ISO-BSR (see ISO/TS 16668).
c) Examples
d) Additional text, comments
e) Allowed values
f) Constants
g) Explicitly given EDIFACT codes or ISO/UN code lists
h) Explicitly given user defined codes
i) Implicitly given EDIFACT codes or ISO/UN code lists
j) Implicitly given user defined or other codes not listed within the EDIFACT code directory
k) Rules to which data element values shall fit
l) Mapping to fields within applications and flat files, respectively
5 Requirements of derivation rules for schemas
a) The MIG technical information as listed in section 4 shall be incorporated into schemas as necessary.
b) The structure of the underlying MIG must be comprehensible (both the XML and traditional EDI guides
shall be compatible in structure).
c) The resulting XML messages should be as lean as possible.
d) One of the different variants by which semantic facts can be represented in XML is specified by this
standard as being mandatory.
e) The developer of a MIG decides which data is important and which structures are meaningful for his
application. By this, he decides which structure elements shall be incorporated into the schema.
6 Rules for the generation of XML schemas derived from EDI MIGs
NOTE The namespace ‘din’ in the examples of this section is for example purposes only and can either be omitted
or any other suitable namespace can be used.
6.1 Rule 1: Tag naming
6.1.1 Variant 1
The names of the XML structure will be derived from the EDI tags. They will be given a prefix depending on
the structure level (segment group, segment, composite data element or data element):
„M_“+ message type + [suffix]  Example: M_ORDERS
„G_“+ segment group + [suffix]  Example: G_SG36 or G_LIN_ALC
„S_“+ segment + [suffix]   Example: S_LIN
„C_“+ composite data element + [suffix] Example: C_C082_2
„D_“+ data element + [suffix]    Example: D_3035 or D_3035_10
The suffix is optional and can be generated based upon various semantic understanding of EDI elements.
4 © ISO 2002 – All rights reserved

If the XML schema file is being generated from an EDIFACT MIG only prefix "D_" would be necessary.
However, as the other prefixes have to be used by those EDI standards which identify composite data
elements and data elements by using numeric tags, they are mandatory.
The second notation of segment group tags can be used when the based EDI standard that is being
converted from provides no explicite segment groups or whenever the notation of the relevant trigger
segments is prefered. In this case the nesting of the segment groups has to be given as sequence of their
trigger segments.
The W3C XML recommendation requires ”self-explanatory tags“. EDI[FACT] tags fulfil this condition better
than tags in natural language, because they represent an established Lingua Franca for EDI specialists.
Example:














6.1.2 Variant 2
From suitable comments ”speaking" tags can be generated if desired. If using "speaking" tags the EDI origin
of the corresponding element shall be documented by an appropriate attribute value (see also section 6.9) or
with other means of documentation.
Example:









maxOccurs="10"/>




...




fixed="ORDERS.SG2.NAD.C080.3036(0120:040:01)"/>
...