🚀 go-pugleaf

In article <E5v7qE.D85@world.std.com>,
Joseph H Allen <jhallen@world.std.com> wrote:
>It's time to start "Free EDI".  ...
>There are two big problems with EDI as it currently stands.  First, the
>standards process is membership based and copies of the standards themselves
>cost lots of money. ... This results in EDI being very non-open and
>inaccessible- supposedly only 20,000 businesses in the US use EDI.  One
>tends to think of the X12 committee existing for the sole purpose of
>supporting itself.  The only books you can find on EDI are content-free and
>read as sales pitches for EDI VANs and the standards committee.

>The second problem is that EDI is only a high-level document
>standard, not a low-level communications protocol.  This has the
>effect that when two companies wish to communicate with each other,
>they must pay a "VAN" (Value Added Network) gobs of money to
>accomplish this goal ...

It's not that bad, there are some real books, and the standards are
readable.  If you don't like X12 you can use EDIFACT or some similar
standards.  Companies are doing EDI over the internet 
(see www.premenos.com for example).  But the main problem with
your idea is the way EDI is actually used.  Generally EDI transactions
are between a big company (say General Motors) and a small company
(say Foobar Ball Bearings Inc, which supplies parts to GM) where the
use of EDI is dictated by the big company and the small company
goes along with it to get the business.  And it's the big company
that gets to choose which standards will be used, which VANs will
be used, etc. so of those 20,000 businesses using EDI, only a few
(the big ones) are making these decisions, and they tend to stick
with what they're already doing and they're big enough to not care
about the cost of a set of X12 books or whatever.  

> - A Free EDI transaction will be composed of a set of "tables" (or
>   relations) in the database sense.  Each table is composed of a table
>   header which identifies the columns in the table followed by member
>   records.  The first table of each EDI transaction will identify the Free
>   EDI transaction standard which is being used for the transaction (and
>   perhaps include a version number or other information).

If you want to have a chance in h*ll of succeeding with real EDI
users, you have to use the same formats as current standards in
order to work with the existing popular software packages.  This
isn't as bad as it sounds; you can follow X12 syntax (segments,
elements separated by *'s, etc.) without having to use the actual
X12 segments or elements.  But you should stick with the same general
organization so implementers need only to add new tables to use
their existing translators.

As for companies not already using EDI, they're probably best off
doing web based transactions, SSL, and maybe defining some kind
of syntax for documents based on HTML tables.  EDI as it currently
exists comes from the Cobol era and is best used by shops still
living in that era.

So I don't have much belief in the need or prospects for a 
new and free set of EDI standards.  But it will be interesting
to see what you come up with.

--Paul (main designer of Premenos EDI/e translator back in the 80's).