[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: XML Gave A War, But Nobody Came
Robert, 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. Regards, 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: >[snipped] > >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. Comments? Robert Dakin ___________________________________________________________ Dr Robert Dakin Dakin Technology daktec@pcug.org.au 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]
Powered by eList eXpress LLC