| 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 - Information can still be transported on floppy disk | -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 |
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. 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.. 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=">"/></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 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. Does 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 EDI solution. 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 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. (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 EDI?
XML's formatting is easy and very understandable. Users do not have to be taught that it consists of tags to describe 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.
Click here to download Framework EDI 
Please read other articles relating to the topic:
Other Topics
| 
315
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
