OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: XML Gave A War, But Nobody Came

> From: Bob Haugen <linkage@interaccess.com>
> To: "ebXML@lists.oasis-open.org" <ebXML@lists.oasis-open.org>
> Subject: RE: XML Gave A War, But Nobody Came
> Date: Thu, 1 Jun 2000 22:31:23 -0500
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Jon Bosak wrote:
> >While I agree that it's not possible in most cases to define a
> >single *simple* standard PO (or whatever) that will suit all
> >purposes, I believe that it is possible (a) to define a horribly
> >complex standard PO that will suit just about all purposes, and
> >more interestingly (b) to define a reasonably small number of
> >standard POs that will serve just about all purposes.
> >But only time will tell whether the second hunch is right.
> (not to pick on Jon out of context, but I need a quote to hook 
> my question:)
> Has anybody made a commonality and variability analysis
> of purchase orders in EDI to determine how much is
> common and where the variability resides?
> (That might help to ground some of this discussion.)
> Respectfully,
> Bob Haugen
> (who doesn't even like purchase orders...)


I won't debate the merits of Purchase Orders, but I would like to
address your primary question, which is a real time problem.

Right now a team at EIDX/CompTIA is working on trying to understand
precisely the type of situation to which you refer.  However, it's not
just a matter of comparing segments and elements to determine
commonality.  An additional issue is to understand that a document like
a Purchase Order can range from a very simple document to an extremely
complex document.

In the computer industry, for example, one can have a single line PO to
order something like a memory card.  Conversely, one can also have a
highly complex PO for ordering complex system configurations, of which
no two are exactly alike.  In the latter example, the structure of the
PO (or any other document meant to convey the information) becomes
important (i.e. nesting, multiple layers, etc.).  So even if you ensure
that all the elements of the different flavors of a particular EDI
document are common, you should also consider the ability to structure
the elements within a given document.

William French			Sun Microsystems
Senior eCommerce Manager	901 San Antonio Road
CS eSun 			unwk 12-204
				Palo Alto, CA 94303

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC