The past as the future
John MacDowell on EDI:
"The format itself is hard to work with compared with XML due mainly to the lack of tools. If every language had an open source EDI parser (or two) and a transformation tool like XSLT would everyone be using EDI today?
http://www.mcdowall.com/2005/04/edi-simple-enough.html
9 years ago, I was working for an EDI Value-Added Network (VAN) as a programmer writing applications to connect organizations up to the VAN. There were only two programmers at the VAN, and it was our job to write client applications that sent and received EDI messages, usually converting them from a different format into EDIFACT [EDIFACT is the EDI format used in Europe]. One application that converted from flat files into IFTMIN messages. Another took the output from a medical application and converted it into HL7. Many other applications made minor changes to documents that conformed to the same EDI specification, for example when two companies differ on how they express dates and times. Our applications then packaged the EDI documents into X.435 attachments to X.400 messages. These were then sent into the VAN.
At the time, there were also graphical tools to do the same EDI conversion job, tools such as Atlas from GEIS, but these were pricey enough to paying a developer to write code instead.. Nowadays, you may consider writing XSLT for the job. But I'm not sure how much of a step forward XSLT is from what we were doing. I've also written XSLT for XML conversion, and it really didn't seem like a solution for EDI messages: too difficult to maintain or and difficult to handover to another developer. I suspect there is always a better answer than XSLT. So, I think XSLT is not the big advantage which XML has over EDI.
So if it's not XSLT, then what is the big advantage of XML compared to EDI? What about the human-readability of XML. Well, I used to read EDI messages and I am human. I guess I knew what to look for, having worked with the specs. I knew "DTM" means "Date and Time" and then if it's followed by "20042005" that means the 20th of April 2005. And, of course, EDI messages are not meant to be read by humans anyway. Nobody ever rang the VAN helpdesk and said "i can't understand this EDI file". It wasn't an issue.
So what is the big advantage of XML-over-the-Internet versus EDI-over-a-VAN? My view is that it is simply the cost of transmission and the cost of setup. There is no need to pay for content by the byte anymore. EDI-over-Internet specifications such as AS2 allow HTTPS and S/MIME to be used to send XML over the Internet. The S/MIME option feels more like the EDI which I am used to: store and forward.
But, on the flip-side, what benefits had EDI-over-a-VAN versus XML-over-the-Internet? Well, the X.400 email system, which we used for our EDI VAN, produced delivery receipts that are lacking from SMTP-based email. When "internet email", as we called it then, became popular, it seems like a step backwards from X.400. Specifications such as WS-ReliableMessaging will fill this gap. EDI documents are also smaller than XML documents, and so travel on the network faster.
To some degree, XML-over-the-Internet technologies are still playing catchup with the EDI-over-a-VAN systems we were rolling out 9 years ago. It all reminds me of a conversation I had with a HTML developer colleague back then. The "old school" EDI team were just down the corridor from the new Web designers which had just been hired. This was about the time when frames were the new innovation. He said "one day, business data will flow electronically between businesses, all automatically". I nodded, and went back to my desk to finished up an EDI application I'd been working on.
12:42:45 AM 
|
