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