Over on the Inovis blog, Bill Chessman ponders about the human readability of XML vs. EDI.  A different take on an old debate. 

Ah, the old “EDI vs XML” debate rears it’s enormous jumbo head of dissent again…  *sigh…..

XML is simply a language for possibly trading information in a human readable format.  Much like HTML (the language of the Internet), you use “tags” that tell you what the next piece of information is.  So you can have a simple tag of <NAME> and then a person’s name and then the closing tag </NAME>….  You can continue to use these simple kinds of tags for the rest of the information you’re sending (sending maybe an address, a 2nd line of address, a city, a state, a zip and more) and the human eye can read it as

John Smith
123 Main Street
Suite 123
Anytown
ST
92345

In his post at the Inovis blog, however, Bill makes an excellent point - and one I’ve touted before in other comments - in that XML may be easier (in the layout of tags and direct information) to read then EDI formats, but it’s all dependent upon the DTD and the schema.  It’s easier because there is no rigid, solid standard to follow.  “Data A” can be ANYWHERE in the document, as long as it’s labeled as “Data A”.  The DTD and the schema are a lot like the translation specs we use in EDI - in that it tells you what tags will contain what data and what it all means.

But it’s that same lack of a standard that makes XML so much more complicated and so much less a solid answer.  There’s no specific spot for that “Data A” mentioned above.  It can be ANYWHERE… and it’s the job of the DTD or schema to tell you where it is and what it means.

Kay Dietz (of Inovis) offers a great course (through the training roadshow) on XML 101 - giving you the most basics of basics - kind of like a sample when you’re at the store…  “Here, try this cookie.  Isn’t it the best? Aisle 3B, 4.99 a dozen!“  XML is a great thing - offering a lot of possibilities for the transmission of data between partners.  And it’s supposed to be human-eyes readable.

But that’s where the problem comes in….  If (as Bill mentions) you don’t know what this tag is and means, or you don’t know what the abbreviation or code I’m using is, how can you interpret the data.  And sure, the schema or dtd can tell you what that is, but you have to read it and/or format the document to tell you what it means….

XML is, at its most basic, a language.  Just like Cobol and C++ and HTML and Chinese and French and English and…. Well, you get the point.  But let’s take that comparison even deeper….  XML could be very similar to Chinese or English - in that you will have different variations on the same language, all depending upon who is speaking.  There are many different dialects in both languages.  In the Chinese language, if you have two people speaking two different dialects, then there is a lot that they cannot communicate.  In the English language, at least if there are two people and two dialects, most of it can come across.  This isn’t a failing in the Chinese language at all.

XML can be a lot like English or a lot like Chinese.  It can be similar and yet different or it can be different and different.  Let’s say I’m sending you an order.  I can send it with the tag <ORDER> and then the number and the closing tag (don’t forget that closing tag!)…  But what if you use <PURCHASE> in your own system.  Sure, that schema or DTD will let you know that I’m sending you the purchase order number in that <ORDER> tag, but you will have to look at the schema for that meaning.

In EDI, since there is a standard (whether ANSI/X12 or TRADACOM or ________), you know that if I’m sending an order, it will be in the BEG segment at location BEG03.  Always.  If you’re fluent in the “language” of EDI - the standard you’re using - you know exactly what information is in what segment and where to look for it and what format it will be in and all of that.  Just as if you’re fluent in English, you will know that in the Southern Dialect, “y’all” generally means “all of you” in a more formalized version of the language.

In My example above (about the name, address, etc., tags), the same information is carried in the N1, N3 and N4 segments.  And it also gives you a bit more information by the element designator (ST = Ship To, BT = Bill To, etc.) so you can also have the same information - but in a different format:

N1*ST*John Smith~
N3*123 Main street*Suite 123~
N4*Anytown*ST*92345~

And there you have the same information.  Sure, there’s the added symbols of * as a element separator and the ~ as the segment terminator, but it’s still readable, IF YOU KNOW THE LANGUAGE.

One of the things that Bill mentions (in the posting) is that EDI was not really supposed to be “human readable” - as it is/was a way of getting data from a source machine or system to a destination machine or system.  It was transferring data from My systems to yours.  If you want “human readable”, you create a report.  It prints out and has all the “tags” set up as field names (name, address, address, city, state, zip) followed by the appropriate data.

Hmmm… that’s just like the XML format of the data above - in that it’s now suddenly human readable.  But instead of having to have the user (aka the human) try and figure out what they mean - the report tells them exactly what they mean, because the data was transmitted and then translated via the standard spec.

Look at it this way - suppose you’re a maker/seller of … gum…  Just looking at the pack of Trident White on My desk, there are 12 pieces of gum to a pack.  Now, let’s say that you put 12 packs in a box.  Then there are 12 boxes to a carton.  And 12 cartons to a pallet.  That’s a lot of twelves…

Now I send you an order…

XML - <QTY>144</QTY>

EDI - PO1*1*144*EA*UP*445600456729~

In the XML version, I order 144.  But 144 what?  Each? Boxes? Cartons?  Pallets?  In the EDI version I give you My UOM (unit of measurement) in the line item detail.  To get that information to you in the XML format, I’d have to add another set of tags - like <UOM>EACH</UOM> or similar or tell you what that quantity means in the DTD or schema.  As a matter of fact, each element in the EDI segment has to have its OWN SET of tags for EACH piece of information…..  So now I’m sending all of this information to you - think about any kilo-character limits or charges you may have - and that simplicity of XML - that “freedom” now is costing you extra.

The XML for just that simple EDI line would look something like this:

<LINE>1</LINE>
<QTY>144</QTY>
<UOM>EA</UOM>
<UPC>445600456729</UPC>

Each piece of information for the item being ordered has to have a set of tags to designate it.  And for EACH and EVERY order I send you, you’re getting that same set of tags and data over and over and over again.  For each line item (style) I’m ordering, you’re getting all of those characters that make up those tags - over and over and over and over and….  Whereas with EDI, you get - hey, look - a separator (*)….  So, let’s just do a quick character count of the EDI PO1 segment I’ve got up there…. 29.  29 characters…  The same for an XML version of that line…?  Let’s see .. 14 for the qty line .. um .. carry the one .. divide by .. add .. Where’s that damn calculator..?!?  It came to 64 characters, btw.

 And the more “detailed” I make My tags (use QUANTITY instead of QTY, UNIT OF MEASURE instead of UOM) and you can see how it can REALLY start to add up.  Oh, and then you’re also sending that DTD or schema with EACH and EVERY document.  Imagine if you had to send your translation spec with EVERY document you send..

So, yeah, XML has some benefits in the simplicity department.. and in the “human interface” area.  But with no standards to abide by, no rules to play by, that human readability goes right out the window with whatever dialect you want to speak.