EDI v XML

[BRADENSTOKE]

Can anyone give any advantages of XML over traditional EDI (EDIFACT, ODETTE) ?
I can think of disadvantages only.

Frank.

 

[akw]

Sorry for not answering your question, but there aren't any advantages ...
The only advantage of XML is, there is no standard and you are able to change your messages by will...
In real EDI world, machines are talking to machines, you have to trust your trading partners

-akw

 

[EDIhappy]

Hi Guys,
XML will replace EDI in time. Just as Tradacoms in the UK is being replaced by EDIFACT versions. I agree EDI works well for batch processing, but XML is so much more flexible. You may well have a large data overhead, but once the VAN cost is removed, and replaced by the internet route, who cares how large the data file is.

Also don't forget the CEO's driving the large corps, They usually do it because it's new and looks cool. It does not have to be better, just different. The best thing will be the EDI/XML coverters. Thus allowing systems to works with both EDI and/or XML in any direction, and keeping EDI going for a long time to come.

 

[Crimson74]

Hi,

For exchanging business doucments between external partners EDIINT, not XML, is the way forward. There are too many XML standards out there (which one to use? Support multiple ones?). It's too flexible sometimes (partners can make up different tags for the same things (e.g PO nr.) which you still need to translate). XML files are too big if you are heavily into data exchange. Even if you cut out the VAN, you still need a lot of processing power when you send/receive thousands of messages per day. Thus the smaller the messages the better.

EDIINT uses the best of both worlds. Structured standards over the Internet. Will be big especially since large companies seem to go for it (e.g. Carrefour, Wal Mart)

 

[BRADENSTOKE]

A couple of points to ponder :
An EDIFACT segment such as DTM+200307210730:203 translates to XML as
<DTM name =&quot;DATE/TIME/PERIOD&quot;>
<E2005 name=&quot;Date/time/period qualifier&quot;>
<value>137</value>
</E2005>
<E230 name=&quot;Date/Time/Period&quot;>
<value>200307210730</value>
</E230>
<E2379 name=&quot;Date/Time/Period format Qual&quot;>
<value>203</value>
<E2379>
</DTM>
This is 237 bytes as opposed to 25 bytes.
There are dozens of DTM segments in a message !
It is madness to transmit the manual in every segment, do they think the receiving application has forgotten ?
Even with all the verbosity in the XML it still does not tell you that 203 means CCYYMMDDHHMM and that 137 defines the message creation date.
An XML/EDI converter would only re-create the original message and you still need EDI translation, so why bother ?
XML may be flexible, but this is just what you do not want in EDI. You need regular consistent data which slots seamlessly into an MRP system, and that Planners/Controllers can rely on.
There are EDIFACT standards for just about every kind of information exchange, so there is no need to invent new standards on the fly which only a small group will be aware of. A recipe for very muddy waters.
Frank.

Frank.