EDI vs. XML

What is EDI?
EDI or Electronic Data Interchange is the exchange of information in a standard format between computers without any human intermediary.

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 to use EDI; when the world's energy companies are using EDI; when institutions that are sending people into space are using EDI; when Universities are sending students' records 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.

What is XML?
It's difficult to define XML (eXtensible Markup Language) in one sentence because of its dual function as a scripting language and a file format.  But, it is a technology that has evolved from HTML, which is the language used by Internet web pages.  Both HTML and XML are file formats that allow interaction with their user.  This feature that allows interaction separates XML from other EDI file formats like X12 and UN/EDIFACT.  Because EDI is defined as the exchange of data without any human intermediary, the XML format with its interactive feature does not fit into the definition of EDI without exception; otherwise the XML format (in standard format) would have been considered to be just like any other EDI standard formats.

Why would XML be compared to EDI, or "said" to replace it?
Although, there are some differences between both technologies, there is one function they both have that has a similar purpose, which brings about the debate.  Both EDI and XML formats are structured to describe the data they contain.  The main difference would be that the EDI structure has a  record-field-like layout of data segments and elements, which makes the EDI file shorter, but not easily understandable; while the XML format has tags, which is more easily understood, but making the file bigger and verbose.

Is XML a threat to EDI?
No, XML is good for EDI. Any technology that promotes e-commerce is good for EDI. For a company to fully appreciate EDI (or XML), it has to see its business transactions fully automated, and paperless.  An EDI/XML solution completes this picture of an automated and paperless transaction.  XML actually complements EDI.

How does XML fit with EDI?
XML's principle design is to display documents, or data in a database, onto a web browser for users to view. Thus XML technology facilitates the presentation of data in a form that's readable to a user so that information can be conveyed.  On the other hand, EDI is primarily used for automated transactions free of human intermediary, and therefore need not have to be viewed.  EDI technology is therefore used between machines because the format of the file is not verbose, but unreadable structured codes that efficiently describe and store data into a file so that the file can be transported quicker, and get parsed easier. 

Can't XML replace EDI for automated transactions?
Currently, XML can't replace EDI because XML doesn't yet have standard formats for industry transactions, which would make it difficult to create an automated system to parse business transactions.  The lack of standard also makes it impossible to create a validation acknowledgment file similar to EDI X12 997, which is used to acknowledge to the sender that the file was successfully translated by the receiver.  The XML format also creates files much larger than EDI files.

Is one more efficient than the the other?
They both have their strengths. If we were to replace an EDI transaction with XML, the file can get to be at least five times larger.  For example, below is an EDI segment..

 NM1*WT*1* Smith*John*C.~N3*610 E. Bel Aire Dr.*Suite 300~N4*Burbank*CA*91503

Besides the obvious name and address, the line above has implied information about the field structures (as defined by the EDI standard) - the data type of each element (e.g. alpha numeric); the minimum and maximum field length - and that the person above is a "Witness for Defendant".

Below would be XML's equivalent (with no field structure information):

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

As you can see, an XML file can get to be five times bigger than an EDI file. And file size is very important especially when sending and receiving through the Internet.

Also, an EDI file is a binary file (please visit http://www.edidev.net/edidev-ca/samples/Gen832withPicture/Gen832.aspx), unlike XML which is a text file.  
Therefore, if you were to include image (binary) files into XML, it would have to be encoded first (convert binary characters to text), which would dramatically increase the file size even further.

On the other hand, EDI can't display itself as a document as readily as an XML document.

Does file size really matter now that disk storage is cheap?
The advancement of one technology should not be negated by another, otherwise what would we gain?  It's true that disk storage is much cheaper, but the disk space gained should not store the same 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 is  not  to mean so we can inefficiently transmit larger files that could not be done with dial-up.  It should mean that we can transmit the same amount of information - faster or with more data, like pictures and sound.  Also, CPU processing speed and RAM memory, are cheaper and faster, which should mean that the same same amount of information in a file should be processed in less time, and not so that we can process larger files for  the same information with no time gained.  

Is XML more readable than EDI?
EDI is full of codes which makes it hard to read in its raw format. But the fact of the matter is that since the transaction is between computer to computer without any human intermediaries, we humans shouldn't care about the readability of the raw format of the file. The file should be in a format that a computer can translate and generate best and also in a form most efficient in transporting over the Internet.  Once the EDI file has been translated into a database can applications written in other languages or scripts, like XML, bring the information up in a format of their choosing so that the information contained in the EDI file can be read easily.  Incidentally, XML in its raw format is just as difficult to read as EDI.  The XML format you view in your browser is not the raw XML format, but has already been processed by the browser so that the data are neatly arranged hierarchically, (which can also be done with an EDI file.  Please visit http://www.edidev.com/eFileManager.htm).  Below is a section of a raw XML format as viewed in a text editor.

<?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="&gt;"/></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 raw EDI file as viewed in a text editor.

ISA*00* *00* *ZZ*RECEIVERISA *14*0073268795005 *960807*1548*U*00401*000000020*0*T*>~GS*IN*RECEIVERGS*007326879*19960807*1548*000001*X*004010~

So realistically (and to be fair), neither EDI nor XML should be worked on or viewed at with a text editor, but with their respective and appropriate tools.

Is it difficult and expensive to translate and generate EDI files?
The main difference between processing an EDI document and an XML document is that an EDI document has a standard implementation guideline that one has to adhere to, which  is  not easy specially when every EDI transaction type have their own standard format.  For this reason, an EDI file is always associated with an implementation guideline documentation so that one can know how to parse, create or validate it.  But, following the implementation guideline was a time consuming and very tedious task until the introduction of Framework EDI.  Framework EDI takes advantage of an open-standard, machine readable format file called the Standard Exchange Format (SEF), which contains the implementation guideline in a format that can easily be parsed by a program.  Framework EDI loads these SEF files to obtain the instructions of the EDI implementation guideline so that it can then parse, generate or validate EDI documents correctly.  This makes processing an EDI file as easy as loading the SEF and EDI file into the Framework EDI component, and then simply mapping the data.   What would have taken days or weeks to implement, can be done in minutes.  Not only does Framework EDI dramatically cut cost by decreasing the implementation time, but also makes the EDI processing more reliable and less questionable because instructions are taken directly from the SEF file.  Furthermore, EDIdEv is only $995.00.

What's the difference between EDIdEv and other EDI translators and generators?
EDIdEv Framework EDI includes COM and .NET component designed to be used within your program.  It is not an application like other translators, so EDI functions to translate, generate or validate EDI files are native to your own application, which can be called whenever and however depending on your business logic.  This makes for a more robust tailored EDI solution. 

Is EDI rigid while XML isn't?
Machines don't translate files like humans do; and if there are things missing in the file that it is looking for, wrong information can be obtained. EDI files are for transactions between machines, so EDI applications must be strict to stay within the standard. This rule also applies to XML.  Trading partners would still have to agree on a format before they can actually start exchanging XML files.  Also, EDI is not as rigid as most people think.  It does have a standard format for its messages, but within this standard format, EDI allows companies or industries to include their own requirements.  Click here for an example of how an EDI schema is modified to include a binary segment to support image files in an EDI document.

Does EDI still require a VAN (Value Added Network)?
Before the Internet, the VAN would be the means for EDI files to be distributed among trading partners. The downside of this was that trading partners had to use the same VAN to do business with each other. This had a 'close' design or equivalent to an Intranet. But with the popularity of the Internet, there is no reason why one can't design VANs that can exchange EDI files with each other (like Postal Offices). VANs are great in that they simplify the distribution of EDI files, but companies can bypass VANs altogether, and simply send EDI transactions directly to each other's mailbox.  EDI files are like any other files on the Internet, and needn't be sent and received any differently.

Is an XML system real-time while EDI is not?
The format of a file has nothing to do with the timing of a process.  Real-time processing depends on the design of the system and how readily it allows users to access a company's database.  

Why do some users prefer to use XML?
The biggest advantage XML has over EDI is that its format is easy and very understandable.  One does not really have to know anything about XML before one can understand its format, which basically consists of tags that describe data they enclose.  This simplicity is also the main reason why users tend to initially prefer XML over EDI.  However, its simplicity is also its limitation, which limits XML's advantage over EDI on only simple transactions e.g. data transfer from an e-shopping cart to a database; or data transfer between two users that can vocally interact and communicate with each other to describe the data they've exchanged.  Basically, XML is a step-up from  a delimited file.  If one where to exchange more complex documents like an invoice or health insurance claim, it becomes more difficult to use XML because unlike EDI, XML does not have a standard template for documents.  This makes parsing difficult specially when in XML data relationships are so heavily dependant on tags, which also makes validation almost impossible.  For example, we cannot know if the XML file has included some optional data or have excluded mandatory data in it; which would also make acknowledging to your trading partner (whether to accept or reject the file) very difficult.  It can be argued that XML can be implemented with its existing standard (DTD or SOAP), but enforcing a standard in XML only makes it as complex to implement as EDI.  And yet, it will still  not resolve the inefficiency of its tags for data transfer.  This too may be resolved in the future as XML matures (but I wouldn't be surprised if it comes full circle to become like EDI).  In the meantime, EDI is already here.  It is a complete, well thought-out and comprehensive technology for automated document transfer.  So, why change it; it ain't broke.

Click here to download Framework EDI 

Please read other articles relating to the topic:

• XML: Extremely critical or exhaustingly complex?
  http://insight.zdnet.co.uk/0,39020415,39115499,00.htm

• The truth about XML
  http://www.mckinseyquarterly.com/article_abstract.asp?ar=1326&L2=13&L3=13&srid=21&gp=1

• Why doesn't EDI just die already
  http://www.webservices.org/index.php/ws/content/view/full/39608

• Is XML the Answer?
  http://www.sqlservercentral.com/columnists/dpeterson/isxmltheanswer.asp

Other Topics

• Overcoming the problems of EDI
• An EDI Story
• Q & A.  What is FREDI?
• Framework EDI methods and properties

  Home