It’s all for nothing if you don’t have freedom.

One of the things you may have noticed about Me when I blog, is that I tend to find a quote or a saying or a song lyric or a … something … that makes sense and drives My thinking.  The title of this blog comes from the 1995 film by (and starring) Mel Gibson called “BRAVEHEART“.  For those that don’t know, it’s the story about fighting for freedom in Scotland in the … 1500s?  One of the more “famous” quotes is when Mel Gibson yells out something about how they may kill them (the Scots) but they’ll never take their freedom!

Freedom, however, in something as strict and regimented as EDI may seem like a far fetched notion, but it’s there.  Sure, we’ve got those lovely guides – those HUGE books – of standards and “rules” for the data we’re sending – depending on the document – that tell us what we can send and how it should be formatted and all the rest.  Those standards tell us we should send this information in this loop in this segment in this element and it should be between 2 and 30 characters in length.

But in that rigidity – in that structure – there’s still some freedom.  Just look at the last sentence in the above paragraph – we’re given some freedom in the data – that it can be between 2 and 30 characters.  So there’s some freedom right there.  Then there’s is such a plethora of data and information we can include – information and data that just may not seem like it belongs in the document we’re using.  But we can include it.

We can even have some freedom in what we use to separate our data – whether an element seperator, a segment terminator or whatever.  We have a choice of characters we can use and put into the data flow to show where this piece of data ends and the next begins.

Then, of course, we have a wonderful MSG segment – in which we can include all sorts of “free form” data that can be anything we want to include.  Again, more freedom.  More abilities and places to put information that doesn’t “fit” any one of the stricter and defined elements and segments of the document.  We can send anything – and I mean ANYTHING – in an MSG segment that may be of use to us (as the sender) or to them (our trading partner – the receiver)…  It could be a “please pack in pretty pink boxes” or “have a happy Friday” or “this information is solely for the use of the receiver” or … well, you get the idea. 

And that freedom is an important part of EDI.  Just as freedom is an important part of nearly every aspect of our lives – from where we live, what we do for a living, who we love, what we drive, what we wear and so on.  However, there are times that those freedoms can be curtailed.

Maybe your employer enforces a dress code – you can only wear dark colored slacks, white shirts and simple, mono-chromatic ties.  You can’t have facial hair.  You have to wear black shoes.  You can’t have any personal stuff on your desktop.  Shades of “9 To 5” – an 80’s-era gem of a movie with Jane Fonda, Lily Tomlin and Dolly Parton…  Where the workers rebel against their boss and take control of the division and suddenly life is good and it’s a better place to work!  Ties back into that freedom that William Wallace (Gibson’s character in “Braveheart“) wanted so desperately for his fellow Scots.

These attempts at conformity can truly alter – and not always for the best – the way that the job can function.  If, for example, that MSG segment wasn’t allowed in EDI – and if it was confining and restrictive – we wouldn’t be able to send some of the information to our trading partners that ARE important.  For example – we request that many of our vendors apply pricing stickers to our products.  And we request a certain format and that they include certain information – such as our internal CLASS of the item – on that price tag.  And we use a MSG segment to get that information across to them.  We send, in the PO Item loop a MSG segment with that class number as the data – and we even use another MSG segment to let them (our trading partners) what that MSG segment contains – the data needed for “TICKET ID”.

Sure, I could probably find something in the PO1 line item that I could use to get that data transmitted from My side to theirs, but it’s just … easier … to use the MSG segments, instead.  Maybe there’s not a perfect fit in the existing standards that will “match” up to our CLASS code.  There may be similar things – but maybe I’d rather have the freedom to use that element or data code later on.  Maybe I’ll suddenly have to start sending some other piece of data that the “similar” element was originally intended for.  Where’s the freedom in that?

By putting forward too many restrictions – too many rules – too many standards – you limit what you’re able to do.  You limit what can be done with the data or what you’re sending.  You limit your ability to effectively communicate – and to effectively work – and to effectively get your ideas and points across.  What if I wasn’t able to use movie quotes and song lyrics in My thought process?  You’d not be reading this blog – or – worse yet – it would be boring, dry and as exciting as a textbook on “Analyzing Algorithms about Data Trends in Modern Day Accounting” or something just as … exciting.

Some people have claimed that XML is the “NEW FUTURE” for EDI and that we don’t need standards and we don’t need rules and governing … committees … to tell us what we can and can’t send and how to format it.  They see EDI standards as … constricting … and they can’t see the freedom that is allowed them.

There is freedom all around us in EDI.  The trick is to find it and take it.

“It’s all for nothing if you don’t have freedom!”

Author: Craig Dunham – EDI Coordinator
Read more about Craig here:

EDI vs. XML – how readable is XML?

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

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~

And there you have the same information.  Sure, there’s the added symbols of * as an 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:


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.

Author: Craig Dunham – EDI Coordinator
Read more about Craig here: