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


Bob et al,

Here are some considerations for interest and I believe, applicability to
this question.

Our experience in using UN/EDIFACT Standard for a Purchase Order has worked
like this:

The UN/EDIFACT ORDERS message has around 185 segments
The EANCOM ORDERS message for it's membership is around 85 segments
The Retail Industry here has pruned EANCOM for their use and the resultant
message has a mere 26 segments
And finally, when an individual Company uses the Retail Industry ORDERS
message, they further prune this down to between 12 and 16 segments.

I am sure other Industries would give a similar result. So even if the
original ORDERS message is a monstrous size, when put to practical use the
results are very manageable. Of course choice of elements and codes go
through similar pruning and even more dramatically.

This practice is based on a choice of segments/elements and codes from a
large repository (original message) to enable the business process to
proceed. I feel that the position with ebXML can be just as successful but
instead of the source being a structured message, could we be selecting from
a pool of data similar to the UNTDED of UN/EDIFACT?. 

Now the interesting thing here is that I recall that the VICS EDI
development was a big success, and relief to users, as to select from the
ANSI directory was very trying and cumbersome. Similarly, EANCOM has
achieved success because they have done a similar helpful thing for their
members. Parties consenting to engage in EDI agree on which directory
version they will use, and message version. What we could be heading toward,
is that the only selection available with ebXML will be a total pool of
defined ebXML elements or grammatical rules. 

We would not expect that an end user will engage in such activity and
develop their own ebXML message. It will be up to organisations and like
bodies to develop the appropriate messages. This means that to achieve a
uniform approach across an Industry, it will require a message of a size,
probably too big for most implementations, but sufficient to allow a
selection to be made, and enabling business to be carried out.


Wavell Cole
GE ECXpress
Level 15, 565 Bourke St.
Melbourne Vic. Australia 3000
Office: 61-3-9927 2537, Fax 61-3-9629 8838
Mobile: 0414 781 593
wavell.cole@gxs.ge.com


-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Friday, 2 June 2000 13:31
To: ebXML@lists.oasis-open.org
Subject: RE: XML Gave A War, But Nobody Came


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...)


[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