Recently, I converted my address book application to use vcards, a standard which is widely supported and seems to be highly flexible when it comes to storing and using address/contact information.

In writing code to read, store and translate vcard data, I was reminded of the way EDI is handled. The two have some significant similarities. The upside for vcards is that the standard is readily available only as an RFC (Request For Comment, a standards document). EDI suffers from the fact that a single entity owns all the standards for all possible documents, and it forces you to pay significant amounts to obtain the standards document for any given “transaction set” (e.g. an invoice).

In the process of writing this code, I decided to look up all my old documentation from the days when I was writing EDI code (decades ago). The EDI standard is composed first of definition for various segments. For example:

N1*ST*My Discount Store*92*333

A single line is known as a segment. The first “element” (between asterisks) is the segment identifier. This says what type of segment it is and how to interpret the various fields in the segment.

The fields shown above in order are:

• Entity Identifier Code
• Name
• Identification Code Qualifier
• Identification Code

The “N1” segment has a few other elements, but these are the ones represented in our segment. The “ST” in the first element (after the “N1”) indicates that this name is a “ship-to”. The ship to company name follows as element 2. The last two identifiers are values which the sender and receiver of the EDI document understand. They qualify the name/entity in some agreed upon way.

I’ve shown an EDI document previously. It is composed of numerous segments, each of which are designed to go with a specific “transaction set” (document). Typical EDI transmissions have probably under 50 lines, but they can have hundreds, depending on the transaction and the document type (purchase order, invoice, disbursement voucher).

It should be noted that even though there is an EDI standard for each type of document or transaction, each company may have a slightly different implementation of that standard.

EDI transactions are relatively easy to parse compared to XML. But one of the things I realized when I started looking over my documentation was that EDI is not necessarily a good format for storing data. You’re better off using a SQL database. The SQL back end can do a lot of work for you, but it takes a good designer to design the initial database structure.

What EDI excels at is the thing that XML supposedly (but not really) excels at– the transmission of “standard” data in a compact, easily parsable way. It’s even human-readable, if that was ever a selling point. (It was supposedly a selling point for XML, but I never knew anyone who tried to parse an XML document manually. The mutual agreement on each side of the EDI transaction (transmission and receipt) means that it’s a rather simple matter to parse a transaction set manually (if you wanted to) but particularly with automation.

Vcards are much like EDI documents, but because of the way the standard is implemented, parsing them can be hairy, more so than EDI. I had to veer off the standard in a couple of cases because of the way the standard implemented some items. But vcards are meant to not only serve as a medium for exchange of information (like EDI) but also as a storage format. My address book software reads a flat file of vcards in order to do its job. And it implements a subset of the standard. My parser is geared to my use of vcards, and is not robust when it comes to implementing the standard exactly.

My point here is that, again, EDI and similar standards are superior to XML, and that EDI as a standard is really only good for transmission of data, not storage.