Title: RE: [ubl-lcsc] Newest version of the OO-design position paper.
Hello
Arofan,
XML is
not a hype anymore. One of that reason is the complexity of the business
documents. The most of the business documents have too much hierarchies. More
than EDIFACT or ANSI ASC X.12 ever have. These many hierarchies makes the
business documents very heavy or not at all processable. I know some projects,
which had some big problems with the many hierarchies.
- It
was not possible to put this documents or part of these documents into the
databases
- It
was a big effort to realize any application interface for processing these
documents
-
Additionally, the effort to define a XSLT rule was much more higher as for
defining any mapping rules for EDIFACT and Inhouse formats.
I
guess that the instances itself do not need any containers, because it is easier
to define any interfaces for business objects.
My
suggestion is that we have partial object classes instead of unstructured
containers. This partial object classes makes the building of structure much
more controllable and the partial object classes are reausable,
too.
Otherwise, if we use "containers", than we need some simple rules for the
definition and processing in a automatic manner. One another import thing is,
that the names containers impacts the dictionary entry name. If you use a
container with the name "header", than the dictionary entry name will be
"order.header.id" instead of "order.id". This representation is not ebXML CCTS
compliant.
Kind
regards,
Gunther
-----Original Message-----
From: Gregory, Arofan
[mailto:]
Sent: Dienstag, 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
