XML Schema to the rescue? was RE: XML Gave A War, But Nobody Came

[David Burdett <david.burdett@commerceone.com>]

Cole

You said ... "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."

This has been the EDI way, but with XML schema you have you can "extend"
rather than "subset". This means that you start with a short, small XML
Schema definition of a document that works for the SME and for many
instances in large corporations as well. You can then "extend" it using XML
schema to include the additional data required for specific industries,
regions, etc.

The benefit of this is that:
a) you don't have to think of everything before you start
b) software can recognize all these versions as being essentially the same
thing, so
c) if you get an extended document you can still process it as an ordinary
vanilla one if you need (and it makes sense) to do so

David

-----Original Message-----
From: Cole, Wavell (GXS) [mailto:Wavell.Cole@gxs.ge.com]
Sent: Thursday, June 01, 2000 11:08 PM
To: Bob Haugen; ebXML@lists.oasis-open.org
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...)