OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ubl-lcsc] Newest version of the OO-design position paper.

Title: RE: [ubl-lcsc] Newest version of the OO-design position paper.
Hello Stig,
the most of XML instances will process the apps only. And we have to build structure, which is easy processable by any kind of applications, like databases, user interfaces, workflows, business systems etc. My opinion is, that this structures have the same representation as a OO-designed class diagram for a interface or a database, without any containers or additional hierachies which do not represent any object classes. This makes the implementation much more easier. My feeling is, that XML will be interessting for everyone, if you realize any direct interface to the differenet applications without a middleware for mapping.
Kind regards,
-----Original Message-----
From: Stig Korsgaard [mailto:STK@Finansraadet.dk]
Sent: Donnerstag, 22. August 2002 13:05
To: 'Gregory, Arofan'; Stuhec, Gunther; 'ubl-lcsc@lists.oasis-open.org'; 'ubl-ndrsc@lists.oasis-open.org'
Subject: RE: [ubl-lcsc] Newest version of the OO-design position paper.

Hi Arofan and Gunther,


This is quite interesting and my humble opinion is that I agree with the concerns expressed by Arofan. If the connection becomes too tight you will approach a situation where nothing can be done except this direct relationship exits. This is actually not only and apps question but also a business type of logical issue. I can certainly see the case where the same object structure also from a business perspective could be desirable to be treated differently. One the other I can also how this will increase the difficulty in making a clean set of rules!


Best Regards  


Stig Korsgaard

M.Sc.E., Standardisation Coordinator

Danish Bankers Association

Tel: +45 33 70 10 83

Cell: +45 21 21 82 34

Fax: +45 33 93 02 60

E-mail: stk@finansraadet.dk


-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: 20. august 2002 23:20
To: 'Stuhec, Gunther'; 'ubl-lcsc@lists.oasis-open.org'; 'ubl-ndrsc@lists.oasis-open.org'
Subject: RE: [ubl-lcsc] Newest version of the OO-design position paper.



I have a fairly basic question for you.

Today, most business applications do not view XML business documents as a direct serialization of the objects that they use internally. Rather, the business document represents a somewhat truncated version of the object hierarchy, designed for exchange between applications. While I see the value of having a formal relationship between the model on which the object hierarchy is based, and on which the business document definitions are based, I have always thought that the serialization from one to the other was a very useful level of indirection - different apps may actually want to take the same object structures and treat them differently, given that they generally perform different functions.

You approach removes this level of indirection (as well as all the containers, making it difficult to use for non-object-based systems, a different issue) - are you sure that this is the best approach?

What I am trying to get at here is the middle ground between a strictly object-based approach, and one that will be suited for use by other types of applications, while not losing the merits of what you have outlined.



-----Original Message-----
From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com]
Sent: Tuesday, August 20, 2002 1:57 PM
To: 'ubl-lcsc@lists.oasis-open.org'; 'ubl-ndrsc@lists.oasis-open.org'
Subject: [ubl-lcsc] Newest version of the OO-design position paper.


Hello all,
this is our newest version of the OO-design position paper. It describes generally the definition of aggregate core components as well as the aggregated business information entities.

In this paper all aggregates representing an object. The subelements which are basic business information entities representing the attributes of an objects. An the aggregates insided of an objects are further objects or parts of an objects. The object itself refers to these furhter objects.

In addition all containers are avoided, consciously.  Because it is not possible to represents containers as objects with attributes and influence the representation of a conclusive class diagram unfavorably. 

Please review this document and send me your comments and remarks.

Kind regards,



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC