0% found this document useful (0 votes)
12 views20 pages

XML Approach APCS

The document discusses the integration of XML with EDIFACT standards in the maritime industry, emphasizing that both formats can coexist rather than replace each other. It outlines the definitions, standards, and advantages of XML/EDIFACT, particularly highlighting ISO 20625 as a preferred standard for its readability and widespread use. The document concludes by listing various messages currently in use within this framework.

Uploaded by

fukkelig
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views20 pages

XML Approach APCS

The document discusses the integration of XML with EDIFACT standards in the maritime industry, emphasizing that both formats can coexist rather than replace each other. It outlines the definitions, standards, and advantages of XML/EDIFACT, particularly highlighting ISO 20625 as a preferred standard for its readability and widespread use. The document concludes by listing various messages currently in use within this framework.

Uploaded by

fukkelig
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

EDIFACT to XML approach

in the Port of Antwerp


Agenda

1. XML/EDIFACT Definition
2. XML/EDIFACT Standards
3. Conclusions
4. Why XML
5. Messages in use
First of all…

• 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 !

• 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)
3
1 XML/EDIFACT Definition
“XML/EDIFACT”

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.

5
2 XML/EDIFACT Standards
XML/EDIFACT Standards (1)

• 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">

7
XML/EDIFACT Standards (1)

DTD: XML:

8
XML/EDIFACT Standards (2)

• 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)

9
XSD XML

10
XML/EDIFACT Standards (2)

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

11
XSD XML

12
3 Conclusions
Conclusions on translation standards

• 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.

14
4 Why XML…
Why XML…

• 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

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

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.

17
5 Messages in use
Messages in use

(in alphabetical order)

APERAK
BAPLIE
COARRI
CODECO
COPINO
CUSREP
CUSRES
IFTDGN
IFTSAI
IFTSTA

19
Q&A

You might also like