EDI vs. XML
What is the main difference between EDI and XML?
A big difference between the the two can be seen clearly if we view the files in their raw format. Below is an example of an XML file:
<?xml version="1.0" encoding="ISO-8859-1" ?><EDI-X12-4010><Interchange-Control><SegmentRef Pos="0" ID="ISA" Description="Interchange Control Header"><Element Pos="01" ID="I01" Description="Authorization Information Qualifier" Type="ID" MinLength="2" MaxLength="2" Value="00"/><Element Pos="02" ID="I02" Description="Authorization Information" Type="AN" MinLength="10" MaxLength="10" Value=" "/><Element Pos="03" ID="I03" Description="Security Information Qualifier" Type="ID" MinLength="2" MaxLength="2" Value="00"/><Element Pos="04" ID="I04" Description="Security Information" Type="AN" MinLength="10" MaxLength="10" Value=" "/><Element Pos="05" ID="I05" Description="Interchange ID Qualifier" Type="ID" MinLength="2" MaxLength="2" Value="ZZ"/><Element Pos="06" ID="I06" Description="Interchange Sender ID" Type="AN" MinLength="15" MaxLength="15" Value="RECEIVERISA "/><Element Pos="07" ID="I05" Description="Interchange ID Qualifier" Type="ID" MinLength="2" MaxLength="2" Value="14"/><Element Pos="08" ID="I07" Description="Interchange Receiver ID" Type="AN" MinLength="15" MaxLength="15" Value="0073268795005 "/><Element Pos="09" ID="I08" Description="Interchange Date" Type="DT" MinLength="6" MaxLength="6" Value="960807"/><Element Pos="10" ID="I09" Description="Interchange Time" Type="TM" MinLength="4" MaxLength="4" Value="1548"/><Element Pos="11" ID="I10" Description="Interchange Control Standards Identifier" Type="ID" MinLength="1" MaxLength="1" Value="U"/><Element Pos="12" ID="I11" Description="Interchange Control Version Number" Type="ID" MinLength="5" MaxLength="5" Value="00401"/><Element Pos="13" ID="I12" Description="Interchange Control Number" Type="N0" MinLength="9" MaxLength="9" Value="000000020"/><Element Pos="14" ID="I13" Description="Acknowledgment Requested" Type="ID" MinLength="1" MaxLength="1" Value="0"/><Element Pos="15" ID="I14" Description="Usage Indicator" Type="ID" MinLength="1" MaxLength="1" Value="T"/><Element Pos="16" ID="I15" Description="Component Element Separator" Type="AN" MinLength="1" MaxLength="1" Value=">"/></SegmentRef><Functional-Group-Control><SegmentRef Pos="0" ID="GS" Description="Functional Group Header"><Element Pos="01" ID="479" Description="Functional Identifier Code" Type="ID" MinLength="2" MaxLength="2" Value="IN"/><Element Pos="02" ID="142" Description="Application Sender's Code" Type="AN" MinLength="2" MaxLength="15" Value="RECEIVERGS"/><Element Pos="03" ID="124" Description="Application Receiver's Code" Type="AN" MinLength="2" MaxLength="15" Value="007326879"/><Element Pos="04" ID="373" Description="Date" Type="DT" MinLength="8" MaxLength="8" Value="19960807"/><Element Pos="05" ID="337" Description="Time" Type="TM" MinLength="4" MaxLength="8" Value="1548"/><Element Pos="06" ID="28" Description="Group Control Number" Type="N0" MinLength="1" MaxLength="9" Value="000001"/><Element Pos="07" ID="455" Description="Responsible Agency Code" Type="ID" MinLength="1" MaxLength="2" Value="X"/><Element Pos="08" ID="480" Description="Version / Release / Industry Identifier Code" Type="AN" MinLength="1" MaxLength="12" Value="004010"/></SegmentRef>
Below is the equivalent EDI file:
ISA*00* *00* *ZZ*RECEIVERISA *14*0073268795005 *960807*1548*U*00401*000000020*0*T*>~GS*IN*RECEIVERGS*007326879*19960807*1548*000001*X*004010~
The XML format have tags to describe the data they enclose, while the EDI format does not - making it much smaller than an XML file.
Why is it often said that XML is more readable than EDI?
Usually, when the two file formats are compared, the EDI file is viewed with a text editor while the XML file is viewed with a browser. This is an unfair
comparison because when an XML file is opened with a browser, it is getting processed and arranged in a hierarchical format making it more readable; while a file opened in a text
editor does not go through the same layout arrangement. A more even playing field would be to have both files opened with a text editor; or to have
both files viewed with their own appropriate reader e.g. view the EDI file with an EDI reader such as the EDIdEv eFileManager, and view the XML file
with a browser.
Are EDI files meant to be read by users?
No, the purpose of EDI (or Electronic Data Interchange) is to have computers exchange data without any human intermediary. So it should not even be handled by a user at all (more so be
read). EDI is the exchange of information in a standard format between computers without any human intervention. However, it is
still useful to have a utility that enables a user to read an EDI file just for the purpose of troubleshooting EDI related problems.
Why would XML be compared to EDI, and why do many prefer XML?
Both EDI and XML are structured in a format that makes them easily parsable, which brings about the debate. XML have tags to describe its data making it easy to read e.g.:
<Witness for Defendant>
<Person>
<Last name>Smith</Last name>
<First name>John</First name>
<Middle name>C.</Middle name>
<address1>610 E. Bel Aire Dr.</address1>
<address2>Suite 300</address2>
<city>Burbank</city>
<state>CA</state>
<zip>91503< /zip>
<Person>
</Witness for Defendant>
...while data in EDI are laid out in a pre-defined format without any data descriptions making the file look very cryptic. For example, here's the EDI equivalent of the above XML format:
NM1*WT*1*Smith*John*C.~N3*610 E. Bel Aire Dr.*Suite 300~N4*Burbank*CA*91503
It is XML's verbose and intuitive format that makes users prefer it over EDI's cryptic and simplistic format.
So why can't XML replace EDI?
Firstly, an EDI transaction is between computers, so having a user-readable format is unnecessary because the descriptive tags would just make the
transaction files so much larger. Secondly, EDI documents follow a set of standard schematics called transaction sets intentionally making them have a rigid format.
This makes it possible for computers to validate EDI files before translating them, which is important in an automated transaction. On the other hand, an XML document does not
have a standard template allowing for a more free form format. This may make it easier for individuals to create and manage their own XML files, but a free
form format is not suitable for transactions between computers because computers can't read documents like humans do.
If XML comes up with a standard for all documents, would it then be able to replace EDI?
Possibly. But the implementation of XML would then have the added difficulty of following a guideline, and will therefore suffer the same
complaints EDI get of it being difficult and rigid. Compounding to these issues would be XML's file size that would make it cumbersome to manage.
Does file size really matter now that disk storage is cheap, and computers so much faster?
The advancement of one technology should not be negated by the ineffeciency of another, otherwise what do we gain? It's true that disk storage is much cheaper,
but the disk space gained should not store a larger file with the same amount of information due to inefficiency; it should store more new information. The same can be said
about transmitting files. With the advent of broadband, we are able to transmit larger files, but this should not& mean for us to
transmit unnecessary data, but rather be able to transmit the same size file in less time or a larger file with more new data
like pictures and sound. Also, CPU and RAM memory are becoming cheaper and faster, which should mean that the same amount of information
in a file should be processed in less time; the increase in CPU processing speed and RAM memory should not be consumed processing more data in a larger file for
the same information and negating any time gained.
Can EDI files transmit pictures and sound files?
Yes, an EDI file is actually a binary file therefore picture files and sound files can easily be included in it (see example program),
unlike an XML file, which is a text file. To include picture files and sound files in XML, the binary files
would first have to be encoded into text, which would further increase the size of the XML file.
What is an EDI/XML solution? Do EDI and XML complement each other?
Sometimes they can complement each other. But, we have to realize that a database is the final destination for data in an EDI file. A database is
the mode of storage for data, while an EDI file is the mode of transport for data. An EDI file should be translated directly into a database.
Unfortunately, with some legacy systems, the only way for EDI data to get into a database is by first converting the EDI file into another intermediate file
before manually importing it into a database. This intermediate file was usually in csv format, but is now being replaced by XML. The additional
step of converting an EDI file to XML before storing it into a database is not ideal; but for some scenarios, it is the only solution given their current
situation. Click here for an example program that shows how to translate an EDI file into an XML file.
Why do some say EDI is obsolete? Has EDI become obsolete?
Far from it. When the largest company in the world won't do business with you unless you do EDI; when the US health industry makes it mandatory for claims
insurance to be done in EDI; when the world's energy companies are using EDI; when institutions that are sending people to space are using EDI; when Universities are sending students'
transcripts in EDI; and when a Department of Defense, with the largest budget ever, has an EDI system in place, then surely one can't say
EDI is obsolete.
| Issues | XML | XML reality | Traditional EDI | EDI reality | Think about it! |
|
E-commerce Standard |
- New technology - Internet based, easy to implement |
- Many standards of multiple complex frameworks - Not as simple to implement |
- Old, passé electronic standard |
- Time tested and successfully works - Straight forward to implement |
- Why change it; it ain't broke |
|
Cost |
- Cheap to implement and cheaper to deploy via the Internet |
- Tools and developers still cost money - Consumer still pay for Internet connection - Bandwidth usage can be costly |
- Traditionally expensive |
- Cost of tools are getting cheaper e.g. EDIdEv Framework EDI - Can be implemented over the Internet - Less bandwidth |
- Why segregate when you can integrate |
|
Data Representation |
- Intuitive, easy to read |
- Verbose - Time consuming to implement - Storage requirements increases |
- Cryptic |
- Once understood, quick to implement - Storage requirements are minimal |
- Does the consumer really care - Does your developer really understand |
|
Companies pushing the technology |
- New economy companies |
- Consulting companies - High business risk |
- Established companies (Fortune 500) and governments |
- Status quo - Established global user base - Low business risk |
- Make a business decision not necessarily a technical one |
Click here to evaluate the Framework EDI
Related Topics
