Previous Next Table of Contents

1. Introduction

EDIFACT often called " nightmare of paper less office " once you show a programmer the standard draft. Those 2700 pages of horror full advisory board English has cursed many programmers with headaches.

EDIFACT is trying the impossible: a single form for the real world.

Orders, invoices, fright papers, ..., always look different, if they come from different companies. EDIFACT tries to fulfill all needs of commercial messages regardless of branch and origin. Of course those 99% real world is neither simple nor complete. Nevertheless its important for the top companies and their suppliers, you know those who can pay a mainframe and a pack of gurus, and in use since 1995.

XML/EDI is will provide a simpler (KISS) format that can be translated from and into EDIFACT, to allow smaller companies to avoid slaughtering forests and retyping stupid lines into a computer keyboard printed by other computers.

This is NOT XML/EDI, its certainly not KISS. The edifact03.dtd reflects the original words of the EDIFACT standard as close as possible on a segment, composite and element level.

This DTD simplifies EDI in so much as it doesnt distinct between e.g. INVOICE or PRICAT but only defines a generic message type called edifact:message. The benefit is of course that its possible to convert any EDI message into edifact. The drawback is that the dtd is realy relaxed. Validation of EDIFACT message design can therefore not be done by a validating XML parser. Message designers will still need knowledge about EDIFACT message design and EDIFACT tools.

But once the message is designed its simpler to read it with XML.


Previous Next Table of Contents