Please don't attribute any of the below conversation to me. I DIDN'T WRITE
IT!!!
-----Original Message-----
From: Akula [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 19, 2001 10:41 PM
To: [EMAIL PROTECTED]
Subject: Re: XML/EDI - Why does it have to be so hard?
I know nothing of COBOL. I am fairly conversant with EDI. While it may, in
fact, be necessary, to be conversant in COBOL to be conversant with an EDI
Purist, it is not mandated.
Just a few things below...
"Lemme, Paul" wrote:
>
> 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.
>
>
Aha- but they aren't. Isn't one of the beauties of something like Oracle
that
it has a VARCHAR that can store a variable amount of info - you don't end up
tying up storage space (or, for EDI people, characters to be sent to the VAN
on
a per-character basis)?
> Which is itself a structural limitation that clashes with
> how things work in the real world.
>
Huh? My garage is a different size than yours. We can probably park either
one
of our cars in either garage. Not either one is the same size nor takes up
the
same space. Not everything is ordered into nice neat columns. If I had a
garage, which is beside the point.
>
> > 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...
>
Disk space? No, that's the Y2K problem. VANs charged by the character.
Similar, but slightly different - disk space can be a one-time charge, and
you
can back up onto tape. Comm charges are recurring every time you send an
order,
every time you receive an invoice. And think, how many dates to you send in
business documents a year? A couple million? Times two? At a quarter a k?
You could save that many bytes by stripping out "19"??? That adds up
quickly,
much quicker than a simple matter of disk space to keep the files.
>
> 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.
>
Heh heh heh - no, we call that the "837 - Health Care Claim".
>
> 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.)
>
And that we call <drum-roll> X - M - L ! ! !
>
> 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.
>
And who is going to maintain - not just the data dictionary - but the global
record layout template for an order? Having to change a single field early
in
a...never mind.
>
> 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.
>
Yes, spending years trying to figure out a strategy for a pilot program to
implement a model parallel b2b concept is pretty damned sexy and cool, but
EDI
works... today... <shrug>.
--
Rob McNeece
Principal Architect (Airmobile)
Entity-to-Entity (e2e) Integration Solutions
New Era of Networks
c-(703)622-3155 f-(703)847-8882
[EMAIL PROTECTED]
The above opinions are solely and totally my own, or those of the aliens
that kidnapped me last night and subjected me to several painful anal
probes.
=======================================================================
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/
