[ubl-ndrsc] RE: [ubl-lcsc] Newest version of the OO-design positionpaper.

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

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

Gunther:

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.

Cheers,

Arofan

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

      Gunther