The Inovis Blog

If you’ve seen my past posts, you know I’ve spent a lot of time on the discussion of EDI vs. XML. In part it’s been a quest to understand why trends seem to flow as they do. Back in December, in response to a post I wrote, Tom Reynolds said as part of his comment, “Let’s admit that EDI is humanly unreadable (this is its real weakness) and XML’s great strength is that it is humanly readable.”

On the surface, this seems like a reasonable statement, but the more I’ve thought about it, the less I agree. While I agree EDI is pretty much unreadable, I would suggest that is not a weakness since EDI was never intended to be read by humans…the whole point was to transfer data between computers without any human intervention. As it turns out, its true weakness is that it is not used consistently by all and it is hard to troubleshoot because it’s so compact and hard to read.
Therefore, it follows that the advantage to XML (in a comparable computer-to-computer-without-human-intervention scenario) is that it would be easier to troubleshoot because the data is so readable.

However, having said that, I also disagree about XML’s readability. While it is possible to create XML that is readable (assuming the tags and data are in a language the reader understands), there is nothing whatsoever that forces it to be so. One of the early attempts to convert EDIFACT EDI data to XML format resulted in pretty unreadable documents that used the specially formatted element names (based on the EDIFACT directory names) as the tags. Codes were translated to their corresponding descriptions. Using that approach, the receiving system would have to interpret the text (which, it was hoped, would be consistently written and complete) so that the data could be transferred to the back-end application (probably in the form of an “unreadable” code).

In fact, even if the tags and the data are all recognizable words, there is no guarantee as to the semantics (the meaning) of any of it. If I wanted to (not that I necessarily do), I could create an XML document in which the tag could be used to indicate the purchase quantity and could be used to identify the unit of measure (which might or might not be a code). Assuming I have a DTD or schema that spelled out those tags in the hierarchy, my XML document would be just as valid as any other DTD- or schema-defined document out there. Sure it would be possible to pick out recognizable words in the XML, but the meaning would be obscure at best and impossible to determine at worst.
…And, without meaning, it really doesn’t qualify as readable.