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


I think you will see a broad mix of expertise in the ebXML groups.  The closest
to object modeling is core components.  However they seem to be working at a
pretty basic OO level.  I have not seen any discussions of the application of OO
technology to a heirarchical data model and the subsequent limitations that
should be used in modeling.  Most of the modeling I have seen does not seem to
concider implementation constraints.  Polymorphism and multiple inherentence are
not well supported in this (heirarchical) data model and are also difficult to
implement in many of the proposed languages.  Our concern (company not ebXML)
being that version one of these object models will quickly be followed by
version 2 as they are attempted to be implemented.  Fortunately most of the
groups are attempting proof of concept demos though I have not seen much of this
work published yet.

John Motley

Robert Dakin <dakin@pcug.org.au> on 06/01/2000 09:48:19 PM

To:   ebXML@lists.oasis-open.org
cc:    (bcc: jmotley/Globaltechltd)

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

On Thu, 1 Jun 2000 12:31:14 -0500, Rachel Foerster wrote:

>Therefore, why not spend our collective efforts on developing a common
>framework/infrastructure that will support interoperability of any and all
>variants? That's much more achievable than developing a single common
>document format and then getting the world to adopt it.

Having lurked for some time, I am venturing from my bunker to say
a few words.

I would have thought that he natural OO approach would be  to
think of a PO (or whatever) as a class and develop a tree of PO's.
The root of the tree would comprise a common subset of data
and functionality, and descendent classes would elaborate parent
classes to satisfy real application contexts.
Root classes would most naturally belong in Core Components.

I had assumed that an OO approach to EC would include this idea,
extending to multi-transaction scenarios - but I have
not seen much evidence of this way of thinking in recent ebXML
material.  Please correct me if I have missed something.

By exploiting polymorphism and inheritance it should be
relatively easy to construct software components that handle
any of a subtree of PO's or whatever and achieve interoperability
between them.


Robert Dakin
Dr Robert Dakin
Dakin Technology
Home page:   http://www.pcug.org.au/~daktec/
Tel: +61 2 6255 1436  Fax: +61 2 6255 1304

= 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                           =

[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