🚀 go-pugleaf

In article <E5wM2y.2E0@world.std.com>,
Joseph H Allen <jhallen@world.std.com> wrote:
>>...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.
>
>Sigh.  Yes mob-boss rule is exactly the problem, and one which is difficult
>to solve.  All I can say is that to change the process it will help if there
>is a developed alternative.

The thing is, EDI just doesn't benefit smaller companies that much.
The people who really gain from EDI are the ones who have to deal with
a -lot- of different trading partners, and that means the "mob bosses".
The smaller companies who trade with them just consider EDI to be a
nuisance and wouldn't bother with it even it were free, if their
larger partners didn't insist on it.

>>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.
>
>I don't think I want to use any of the existing EDI formats (although I
>would love to hear more contrary arguments- I'm certainly no EDI expert). 
>Although it would certainly be nice to be able to translate into them.

The only reason I see for doing free EDI is to make it easier (cheaper)
for small companies to trade with large EDI users.  The large users
are using existing standards and won't be interested in changing to new ones.

>From what I gather, each EDI standard requires almost a parser (even though
>the EDI standards themselves are not formalized context-free grammars, BNFs
>or regular expressions), and a generic EDI translator essentially is a
>parser generator- one of the most complex pieces of software one can write.

It's not that bad.  The EDI standards are all quite similar in
structure although the terminology varies (EDIFACT calls "sentences"
what X12 calls "segments" if I remember properly).  I wrote a generic
translator; it wasn't that complicated.  Remember that EDI was
designed to be processed by Cobol and RPG programs.  I had to explain
that to several of the programmers who joined the project I worked
on--that EDI is low tech, and if they were trying to approach it with
parser generators and other fancy methods, they were probably thinking
of the problems in the wrong way.  The one thing that didn't fit into
the generic framework was the X12 HL segment, a kind of recursive bill
of lading that nobody actually used or understood as far as I could
tell, but we had to support it because it was in the standard, so I
put a special hack into the translator for it.  The generic translator
was a simple recursive descent "parser" driven by a machine readable
document description that came pretty much directly out of the
standard.

>The approach I'm thinking of is to make Free-EDI transactions look like
>databases.  The software to read a transaction into a relational database
>system should be trivial (and you only need one trivial parser).  Once the
>data is in the database, one can use the database system to map vender's
>codes and customer's codes, merge the data with the custmer's database or
>whatever.

Relational databases aren't really what you want.  EDI documents are
more like tree structures, with repeated segments, nested loops, etc.

>Free-EDI transactions should also be UNIX friendly.  You should be able to
>use UNIX's database commands: sort, uniq, awk, join, etc. and be able to
>build simple shell-scripts to process Free-EDI data.
>
>Free-EDI transactions should also be Visual-Basic, MS-Access and MS-mail
>friendly. 
>
>I don't know much about it, but it would certainly be nice if Free-EDI
>transaction could be AS/400 friendly as well.

If you don't mind my asking, why are you interested in EDI if you
haven't been using it?  I'm not trying to give you a hard time;
I'm just wondering.

>The Free-EDI web site should be a depository for all of these utilities.

You have a web site?  Where?
Thanks.

Paul