It's time to start "Free EDI". EDI (Electronic Data Interchange) is an old
set of document standards designed to allow businesses to communicate with
each other. Typical of the business transactions covered by EDI are
wholesaler to retailer communications: the retailer sends a PO (Purchase
Order) to the wholesaler, which then sends the ordered materials to the
retailer. Then the wholesaler sends an Invoice to the retailer.
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 (VANs charge per
transaction, per byte, per minute, for data conversion, per month, and for
just about every other conceivable "service"). VANs are completely
redundant in these times of cheap modems and the low-cost Internet.
"Dread" is the feeling any company gets when thinking about communicating
electronically. Any money you save from not requiring as many data-entry
personnel is ofset by the VAN fees and the EDI consulatants required to make
the system work. Often companies are forced to use EDI anyway- for example
large retail chains may force their vendors to use EDI.
Free EDI would be a public set of standards (down-loadable for free from any
web site which wants to carry them) which allow companies to communicate
with each other either directly (modem to modem or what have you), or
through the Internet. The process of establishing a standard for a
transaction would be based on the Internet "RFD" (request for discussion)
model. Basically, someone proposes a standard on a USENET newsgroup. A two
month discussion period follows, in which anyone interested gets to append
or modify the standard. A vote is then taken and the standard is considered
established if there are more yeas than nays. The real test for the
standard would be if companies actually used them. If a standard seems
insufficient for a set of industries, they are perfectly free to establish
their own set as long as it is publicly available.
To start things off, I'll propose a common structure for Free EDI
- The communications system for Free EDI will be SMTP-TCP/IP Internet
e-mail. The advantage of this is its universality. Everyone has access
to Internet e-mail and SMTP-TCP/IP is very common for "intra-nets" as
- Security will be based on the defacto internet security system: PGP.
Each message will have a PGP signature from the sender and will be
encrypted with the recipient's public key. This will be sufficient
security so that even EFTs (electronic fund transfers) can occur through
- Free EDI will be transaction based in the database-locking/rollback sense.
Each EDI transaction will be completely executed or have no effect (no
partial transactions). Several transactions can be sent in each email
- Transaction IDs will be universally unique. This will allow Free EDI
transactions to be broadcast via USENET or in USENET-like environments.
If the recipient receives the same transaction twice, the second one is
ignored. The recipient must keep a list of recently received
transactions so that it knows which transactions to ignore.
- An un-encrypted Free EDI message will be in readable text.
- 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).
- An un-encrypted Free EDI message will have this detailed format:
(In general, ASCII text will be used. Each line is terminated with a
line-feed preceded by an optional carriage return).
Begin Free EDI Message
The TRAILER can contain any data. The HEADER can contain any data
except the line 'Begin Free EDI Message'.
Each line in the TRANSACTIONs section will be limited to 77 characters
(excluding the end-of-line sequence). Long lines will be split into
short lines as follows: any line ending with a backslash '\' followed by
a line beginning with a '+' will be considered the same long line
(excluding the \, line-feed, + sequence). Transaction lines will only
use characters in the range 32 - 255 plus 9 (ASCII tab).
There are several types of transaction lines, identified by the
first character (whitespace is to be ignored in these formats: if a space
is required, the word SPACE will be used):
X string Start of transaction. 'string' identifies
E string End of transaction. 'string' must match
the one at the beginning of the transaction.
T name tab COLUMN-DEFs Table header. 'name' is the table's name.
COLUMN-DEFs are a tab-separated list of
column definitions. The number of
COLUMN-DEFs is the number of columns in the
table. The order of the COLUMN-DEFs must
match the order of the corresponding fields
in the data records.
Each COLUMN-DEF is a space-separated list
of symbol/value bindings. Two bindings
are required for each column:
name=xxx 'xxx' is the column's
type=ttt 'ttt' is gives the
column type and is one
int Decimal integer
frac Decimal fraction (a number
with an optional decimal point).
date A date in the format:
Month Day, Year
Where Month is: Jan, Feb, etc.
A name tab FIELDs Add a data record. 'name' is the table for
which this record is for. FIELDs are a tab
separated set of fields. The number of
fields must match the number of columns. Any
fields can be empty, no matter what the data
type. The seperating tabs are required for
even for empty fields, however.
Each transaction begins with a 'T' line and ends with an 'E' line.
Table headers and data records are contained within the transaction. The
table header must be given before any data records for that table are given.
The first table is always the 'transid' table. For example:
Ttransid name=id type=str name=ack type=str
Atransid eft1 free-...@motorola.com
Might be the first table for an EFT-type transaction called 'eft1'.
An acknowledgment for this transaction is to be sent to the given
e-mail address. A complete EFT transaction would also have
Teft name=frombank type=str name=fromaccnt type=str\
+ name=tobank type=str name=toaccnt type=str\
+ name=amnt type=frac
A 123456 12397654 123456 12387654 1259.37
- an order to transfer $1259.37 from one account to another of the
Please start discussing the sufficiency of this as a data format.
To move on from here we are going to need a newsgroup for discussion (I have
no idea how to start the process for newsgroup creation) and an ftp site
for recording the standards. I can donate an ftp site (ftp.worcester.com),
but it is slow and should probably be mirrored by others. Another issue is
the name: 'EDI' probably violates someones trademark, so we need a new
/* jhal...@world.std.com (188.8.131.52) */ /* Joseph H. Allen */