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

["David S. Frankel" <dfrankel@gendev.com>]

Regarding schemas addressing reuse better:

As an aside I would add that the reason that XMI DTDs look a bit strange is
that, since UML/MOF are OO and thus support reuse very efficiently, and DTDs
are not, the XMI architects were mimicing inheritance by generating extra
ENTITY declarations.  This has produced the most common complaint about XMI,
namely that it looks unnatural (although perfectly legal) with all those
ENTITY declarations.  If schemas address reuse well, a new pass at XMI will
yield much more natural-looking XML.

--Dave

================================
David S. Frankel
Chief Scientist
Genesis Development Corporation
741 Santiago Court
Chico, CA 95973-8781 USA

+1 530 893-1100 voice
+1 530 893-1153 fax
dfrankel@gendev.com
http://www.gendev.com
================================

> -----Original Message-----
> From: owner-ebxml@lists.oasis-open.org
> [mailto:owner-ebxml@lists.oasis-open.org]On Behalf Of Bill Lewis
> Sent: Friday, June 02, 2000 11:33 AM
> To: 'David Burdett'
> Cc: ebXML@lists.oasis-open.org; Bob Haugen; Cole, Wavell (GXS)
> Subject: RE: XML Schema to the rescue? was RE: XML Gave A War, But
> Nobody Came
>
>
> I absolutely second this.  XML schema functions such as the "include"
> element, could save the day...if widely adopted.  Assemble larger schemas
> from smaller, more reusable parts.
>
>
> William J. Lewis
> blewis02@ctp.com
> Cambridge Technology Partners
> One Oxford Center, Suite 1200
> Pittsburgh, PA 15219
> Phone 412-454-1632
> Fax 412-454-1800
> Mobile 412-736-7026
>
>
> -----Original Message-----
> From: David Burdett [mailto:david.burdett@commerceone.com]
> Sent: Friday, June 02, 2000 1:39 PM
> To: Cole, Wavell (GXS); Bob Haugen; ebXML@lists.oasis-open.org
> Subject: XML Schema to the rescue? was RE: XML Gave A War, But Nobody
> Came
>
>
> 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...)
>
> ==================================================================
> =========
> This is ebXML, the general mailing list for the ebXML committee
> The owner of this list is owner-ebxml@oasis-open.org
>
> To unsubscribe, send mail to majordomo@lists.oasis-open.org with the
> following in the body of the message:
> unsubscribe ebxml
> If you are subscribed using a different email address, put the address you
> subscribed with at the end of the line; e.g.
> unsubscribe ebxml myname@company.com
> ==================================================================
> =========
>


=======================================================================
= This is ebXML, the general mailing list for the ebXML committee     =
= The owner of this list is owner-ebxml@oasis-open.org                =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml                                              =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml myname@company.com                           =
=======================================================================