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,
Gunther
-----Original Message-----
From: Stig Korsgaard
[mailto:]
Sent: Donnerstag, 22. August 2002
13:05
To: 'Gregory, Arofan'; Stuhec, Gunther;
'';
''
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
AUTOTEXTLIST \s "E-mail
Signature" 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:
-----Original
Message-----
From: Gregory,
Arofan [mailto:]
Sent: 20. august 2002 23:20
To: 'Stuhec, Gunther';
''; ''
Subject: 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:]
Sent: Tuesday, August 20,
2002 1:57 PM
To: '';
''
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
