🚀 go-pugleaf

Hi All

   It all sounds good to me. I would make the following suggestions
for the data format types.

Date should be in the format should be:   Tyyyymmdd.time

T = Time zone letter A through X 
yyyy =  4 digit year
mm =  2 digit month
dd = 2 digit day 
time = optional fractional part of the day (.5, Noon assumed if blank)

All time and dates to be based on UTC using the Gregorian calander.
Time zone leter codes starting at the international date line with A
and proceding East to West .


You should also add a memo (free form text) field type. In the basic
table columbs a memo filed would have a identifier MEMOxxxx whare xxxx
would be a decimal number 0001 through 99999 and refer to a memo
section that would apper after all tables. Each memo entry would start
with MEMOxxxx zzzz on a seperate line. The number zzzz would indicate
the total number of complete lines (including blank lines) or the
memo. Memos would follow the same rules for line length ect. as
specified for other sections.  Multiple records may refer to the same
memo and memos cold be included that are not referanced by any record
(but this should be avodid)

You should also include a binary attachment facility based on the MIME
standard with a record field type to referance each MIME attachment in
a simaler maner to the MEMO type discribed above. MIME attachments
would follow MEMOs. If MIME is not publicly avalible some other
sutable scheme could be used. 

Even if the file was sent in plain text some type of checksum or
fingerprint should be avalaible. This could be based on the
capabilities of PGP or other sutable program.


Clark

Clark.w.hanley@aero.org






On Wed, 19 Feb 1997 19:35:02 GMT, jhallen@world.std.com (Joseph H
Allen) wrote:

>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
>transactions:
>
> - 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
>   well.
>
> - 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.
>
> - 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
>   message.
>
> - 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).
>
>   HEADER
>   Begin Free EDI Message
>   TRANSACTIONS
>   Z
>   TRAILER
>
>   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
>				the transaction.
>
>	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
>							name.
>
>					type=ttt	'ttt' is gives the
>							column type and is one
>							of:
>
>					int	Decimal integer
>					str	String
>					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-edi@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
>	something like:
>
>		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
>	same bank.
>
>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
>name.
>
>-- 
>/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
>int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
>+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
>]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}