I started this post out to be a response to someone's question about XML
vs. EDI, but then it turned into something different...
While I'm definitely no XML expert, here's my two cents on the little bit
that I know...
I've only been dealing with traditional EDI (specifically, ANSI X12) for
the past 4 years. (Before that, I couldn't spell EDI!)
As far as XML goes...I'm learning. I'm struggling to learn as fast as I
can, but I'm still learning.
While it is true that XML is more "verbose" than "traditional" EDI, there's
a reason...inherant within the XML document itself are both the structure
and the content. Not just the content, like traditional EDI. A
traditional EDI document needs to be generated by the "sender" using (in
many cases proprietary) software and then interpreted by the "receiver" by
(in many cases proprietary) software. Both the sending and receiving
software have the definitions of this EDI document within them--not the
document itself. So, naturally, when you move the structure/definition of
the file into the document along with the content, you're going to have a
larger file.
The problem is, if you look at the structures that exist for ANSI X12 EDI
documents (and I can only speak of these since I haven't had the
opportunity to work with EDIFACT), it comes straight from the old mainframe
COBOL world. Look at the structure. It's based on COBOL FDs (file
definitions) for variable length records which were originally intented to
be stored on a reel of tape.
The whole <header record> <A record> <B record> <trailer record> structure
comes right out of the world of COBOL...including looping (a.k.a. "occurs")
structures.
In today's world of relational databases with tables/rows/columns (instead
of files/records/fields), columns are defined to be of a certain data type
and length and from row to row they're all the same size.
>From record to record, fields are predictable.
This presents a conceptual issue for those who have never dealt with
variable length records in COBOL.
(If you've ever worked with variable length records in COBOL, you'll have a
much better understanding of EDI structures...because, they're one and the
same.)
Most of my problem with "traditional" EDI is the way software solutions
have made it so difficult to deal with this variable structure.
XML addresses this by having the structure/definition within the document
itself.
If the appropriate sending/receiving software is written to pull this
structure/definition out of the document and allow the mapper/user to
handle the actual DATA in an appropriate manner (and not be so focused on
structure), then most of the work is done. All the mapper needs to worry
about is getting the data in/out of the appropriate systems.
Or so goes the theory...
But I still have to ask the question, why stick with this whole "variable"
thing?
I can understand completely why it came about. Disk space used to be
either non-existant or rare or very expensive (or all of the above).
Likewise, bandwidth was an issue. The smaller files are, the faster
they'll transmit.
Variable length record structures are very efficient. They take up less
space. And back when they were created, this issue was paramount.
In today's world, disk space is relatively cheap. Plus, we have
compression technologies in place that make it quite easy to compress data
before transmission.
Why not move toward UNDERSTANDABILITY rather than efficiency?
As I learn more about XML, I'm beginning to see that it has a better chance
of being "understandable" (or human readable) than traditional EDI, and
this is a good thing.
But it's still dealing with that whole variable length record concept.
I'd much rather see non-variable structures in electronic data interchange.
If the purchase order is only taking up 10 characters and the field is 30
characters big, then I'm wasting 20 characters.
Big deal.
Use compression techniques and you'll gain a whole lot more than 20
characters over the entirety of the file.
To me, it's more valuable to have UNDERSTANDABLE and PREDICTABLE data
structures.
On EVERY purchase order record I read through, I want to KNOW where to pull
the data from.
I want to KNOW where to pull it from, how big it is, and what to expect.
I don't want to parse through a whole series of complex structures and
dependancies to determine if this looping occurs or that field exists, but
only under these conditions, and so on.
Why is this whole thing so convoluted?
Is it THAT imperative to save a few bytes here and there?
MY opinion is that once XML deals with handling the existing EDI data and
it's variable structures, standards bodies should move toward SIMPLYFING
everything. Get away from these silly structures that were created to save
disk space and bandwidth and get back to making things more easily USABLE.
Sideline:
A lot of why I'm "getting on my soapbox" about this is because I was
explaining to my daughter the other day what I do at work (and why I'm so
stressed sometimes!).
She's a typical kid who thinks computers are just for listening to Brittany
Spears CDs on.
She doesn't know "EDI" from "CPU".
I tried to explain why my job is so complex and so difficult. I tried to
explain how businesses transfer information back and forth and how this
presents problems for EDI people.
And then she asked an honest question...."Why does it have to be so hard?"
....and I didn't know what to tell her.
Dan Tharp
DBA / EDI Specialist
G&D Transportation
50 Commerce Drive
Morton, IL 61550
email: [EMAIL PROTECTED]
phone: (309) 266-1177, ext 292
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
