[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.
|
Hi again Gunther, While recognising your reasoning in terms of what is best for
applications I feel that the approach has some problems. Having gone one step
deeper in the document the following comes to mind looking at the proposed
approach: -
In cutting some containers from the model you actual
seem remodel the original one in the Schema representation – that makes it even
difficult for me to understand. -
Also renaming of some of the objects/attributes (or
containers) seems strange. That would actually imply not being true towards the
original model -
You miss the reusability of objects across messages -
Containers actually are very useful also for apps
freaks in order to logical style information etc. In total actually I think it can be debated how much this approach makes
it efficient. I agree that some can be removed – but all? 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----- 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----- 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----- 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----- Hello all, 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC