Rich: Good points.
"Tharp-EDI"?????..........I like it! :O)
Rich Rostrom
<rrostrom@MANTI To: [EMAIL PROTECTED]
SS.COM> cc:
Sent by: Subject: Re: XML/EDI - Why does it have
to be so hard?
Electronic Data
Interchange
Issues
<EDI-L@LISTSERV
.UCOP.EDU>
03/13/2001
11:20 AM
Please respond
to Rich Rostrom
> -----Original Message-----
> From: Dan Tharp [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 13, 2001 10:06 AM
> To: [EMAIL PROTECTED]
> Subject: XML/EDI - Why does it have to be so hard?
>
> The problem is, if you look at the structures that exist for
> ANSI X12 EDI documents ... 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 intended 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.
I never really did COBOL, myself, so I can't speak to the
similarities of COBOL data structures to EDI.
But I think you place too much emphasis on COBOL.
The real question is - where did these structures
_originate_?
Not in COBOL - COBOL was designed to meet _pre-existing_
business needs.
Tne X-12 850 (the document I am most familiar with) was
designed to follow the layout of a paper purchase order.
Since it is electronic, it has had lots of stuff attached
to accomodate all the variations and extras (e.g. addresses
at header, line, and subline levels).
> 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.
Which is itself a structural limitation that clashes with
how things work in the real world.
> I can understand completely why it came about. Disk space
> used to be either non-existant or rare or very expensive...
> In today's world, disk space is relatively cheap...
You'd rather have fixed-length everything.
Here's another question. What about record sequences?
Should they be fixed too?
What's the difference between parsing a record to
find the third delimited field in a PER record and
checking record tags to find the PER record in an 850?
It might be easier to find the PER if it was always
the Nth record in the document.
But if that was done, then _every_ 850 would have to
have every record, and every field of every record
would have to be filled. Hey Presto! Every 850 is
now several megabytes.
Storage isn't that cheap and never will be.
"Never"??? Yes, never. No resource will ever be
so abundant that it can't be exhausted by users
who treat it as infinite and free. If nothing else,
someone will implement a clumsy algorithm which
consumes it at exponentially increasing rates.
(Every day I encounter Web stuff that uses 10-30
times the storage and bandwidth that is needed.)
The point of X-12 EDI, XML, or a hypothetical standard
in Mr. Tharp's all-fixed-field format is to organize data
in a rigorous manner that can be automatically
accessed - a place for everything and everything in its
place.
In EDI, this is done by sequence - by assigning a
specific meaning to the Nth delimited field of a
record, and relating records by their sequence in
the document.
In Tharp-EDI this would be done by byte position. But
what is saved? A little processing time - and if disk
space is relatively cheap, processing power is _dirt_
cheap.
Part of the power of EDI is its variability. An EDI
document can expand, contract, or sprout substructures
as needed to represent the business object. This variation
follows very rigorous rules. In my experience, having the
data organized by such rules is 90% of the problem -
parsing and processing it is almost trivial.
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
