Think about it!
- New technology
based, easy to implement
- Many standards
of multiple complex frameworks
- Not as simple
- Old, passť electronic standard
- Time tested
and successfully works
forward to implement
it; it ain't broke
- Cheap to implement and cheaper to deploy
via the Internet
- Tools and
developers still cost money
- Consumer still
pay for Internet connection
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
segregate when you can integrate
- Intuitive, easy to read
- Time consuming
understood, quick to implement
requirements are minimal
can still be transported on floppy disk
consumer really care
developer really understand
Companies pushing the technology
-New economy companies
- High business
- Established companies (Fortune 500) and
- Status quo
global user base
- Low business
-Make a business decision not necessarily a
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'
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
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.
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.
When XML comes up with a standard for
all the Transaction Sets, 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 gets of it being difficult. The work of following an
implementation guideline to make automated transactions possible between trading
partners is time consuming, but can't really be avoided.
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..
Smith*John*C.~N3*610 E. Bel Aire
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>
<Last name>Smith</Last name>
<First name>John</First name>
<Middle name>C.</Middle name>
<address1>610 E. Bel Aire Dr.</address1>
</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
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
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
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=">"/></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>
is the equivalent raw EDI file as viewed in a text editor.
ISA*00* *00* *ZZ*RECEIVERISA *14*0073268795005
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 more difficult and expensive to
process an EDI file than an XML file?
A major advantage XML has over EDI is that programming languages have
already included in them functionalities to parse XML documents. So
basically, if you're a programmer, there is no additional cost for an XML
parser, which has been one of the reasons XML is popular. But the XML
parser itself, does not provide a solution for XML's shortcomings of being
large, verbose and lacking of document standards.
EDI have any inexpensive tools?
The main difference between processing EDI documents and an XML documents is
that an EDI document has a standard implementation guideline that one has to adhere
to, which is not easy especially when every EDI transaction type
has its own standard format. One would have to be able to parse and
validate tens-of-thousands of different types of Transaction Sets or
messages. Quite a tedious task if you don't have any tools. But,
EDIdEv has the Framework
EDI tool that not only parses EDI files, but can also validate them. It's
priced at about $995.
What's the difference between EDIdEv and other EDI translators and generators?
EDIdEv Framework EDI includes COM and .NET components 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
Is EDI rigid while XML isn't?
Machines don't translate files like humans do. If there are things missing in
a file that a computer is expecting, wrong information can be obtained, or may
even breakdown the entire processing. EDI files are for
transactions between machines, so EDI applications must be strict to adhere to
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
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.
(For other ways of sending EDI files, click here.)
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 XML over
XML's formatting is easy and very
understandable. Users do not have to be taught that it consists of tags to
data they enclose - it's understood. This simplicity is 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. 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 the file becomes huge, cumbersome, and impossible to validate. It
becomes unmanageable. On the other hand, the appearance of an EDI format
looks cryptic. But once understood, one can appreciate its efficient, well thought-out
and comprehensive design for
automated document transfer. So, why change it; it ain't broke.
here to download Framework EDI
Please read other articles relating to the topic: