EDIFACT to XML approach

in the Port of Antwerp

1. XML/EDIFACT Definition

2. XML/EDIFACT Standards

3. Conclusions

4. Why XML

5. Messages in use

Agenda

• This is certainly not a plea to ‘eliminate’ or change EDIFACT-standards, change

EDIFACT-messages or the way they are used today…

nor to change all EDIFACT-formats into XML-formats

• EDIFACT-messages are very valuable and can be kept in use “as is”

• It’s not an OR story but rather an AND-AND story

So keep using edifact & develop edifact-standards !

3

First of all…

• It is merely a ‘warm call’ to install some XML-Standardization in

the maritime industry

• as an alternative for those who want to use

alternative technologies (for whatever reason)

1 XML/EDIFACT Definition

Whauwww – There is in fact a wikipedia definition for it !

https://en.wikipedia.org/wiki/XML/EDIFACT

XML/EDIFACT is an Electronic Data Interchange (EDI) format used in Business-to-business transactions. It allows EDIFACT message types to be used by XML systems.

EDIFACT is a formal, readable language-for-machine description of electronic business documents.

It uses a syntax close to delimiter separated files. This syntax was invented in the 1980s to keep files as small as possible. Because of the Internet boom around 2000, XML started to become the most widely supported file syntax. But for example, an invoice is still an invoice, containing information about buyer, seller, product, due amount. EDIFACT works perfectly from the content viewpoint, but many software systems struggle to handle its syntax. So combining EDIFACT vocabulary and grammar with XML syntax makes XML/EDIFACT.

The rules for XML/EDIFACT are defined by ISO TS 20625.

“XML/EDIFACT”

5

2 XML/EDIFACT Standards

XML/EDIFACT Standards (1)

7

• XEDI

• Not really an ‘official’ standard

• The names of the XML structure are based on the EDI structure.

(loop, segment, composite, element)

Element are identified by means of attributes, derived from the EDI tags

„transactionSet“+ message type as code attribute <transactionSet code="BERMAN">

„loop“+ segment group as code attribute <loop code="NAD">

„segment“ + segment as code attribute <segment code="BGM">

„element“+ composite data element as code attribute <element code="C082">

„element“+ data element as code attribute <element code="3039">

DTD:

XML/EDIFACT Standards (1)

8

XML:

XML/EDIFACT Standards (2)

9

• ISO 20625

• ISO/TS 20625:2002 (https://www.iso.org/standard/37020.html)“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”

• 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] M_ORDERS

„G_“+ segment group + [suffix] G_SG36 or G_LIN_ALC

„S_“ + segment + [suffix] S_LIN

„C_“+ composite data element + [suffix] C_C082_2

„D_“+ data element + [suffix] D_3035

(the suffix is optional and can be generated based upon various semantic understanding of EDI elements)

10

XSD XML

XML/EDIFACT Standards (2)

11

• ISO 20625

• Variant 2:

“Speaking”, more readable, tags can be used instead of the EDIFACT codes, if desired.

If using readable tags the EDI origin of the corresponding element can be documented

by an appropriate attribute value or with other means of documentation.

<MessageHeader>

<BeginningOfMessage>

<GroupDetailsOfTransport>

<DetailsOfTransport>

<ModeOfTransport>

</ModeOfTransport>

</DetailsOfTransport>

</GroupDetailsOfTransport>

12

XSD XML

3 Conclusions

Conclusions on translation standards

14

• XEDI not really /not a lot in use

• ISO 20625 is a more widespread and more used standard

– variant 1 is less readable then variant 2

– structure optimization leads to smaller, more human readable XML messages

– according to ISO this standard provides “a sound method of representing semantic

facts”

APCS and PoA choose for ISO 20625 standard, variant 2.

4 Why XML…

Why XML…

16

• XML is native supported, out of the box, by most programming languages and tools

• So no (extra) costs & investments needed in extra, often expensive, software needed

for EDIFACT-architecture

• Resources / EDIFACT-specialists are getting more scarce on global software-market

• XML is more easily readable than edifact

• Some advantages in handling XML-messages

– electronic syntax ‘description’ through the use of XSDs,

– which let you easily validate the correct syntax of an XML,

– and which allows you to force correct type-definitions during validation, before

further

coding and processing

We have chosen for XML-messaging instead of EDIFACT-messaging, but …

• with every respect for previous and precious efforts in EDIFACT-standardization

by many organisations or associations – UN/CEFACT, SMDG, PROTECT, …

• by re-using the "EDIFACT modelling language“

XML/EDIFACT reuses business content defined in UN/EDIFACT.

So it’s not only XML, but “XML/EDIFACT”

17

5 Messages in use

(in alphabetical order)

APERAK

BAPLIE

COARRI

CODECO

COPINO

CUSREP

CUSRES

IFTDGN

IFTSAI

IFTSTA

Messages in use

19

Q & A

?