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 trying to provide a simpler (KISS) format that can be
translated from and into EDI, 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 edicooked.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 edicooked:message. The benefit is of course that its possible to convert any EDI message into edicooked. 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.