Title: RE: [ubl-lcsc] Newest version of the OO-design position paper.
Thanks Gunter. I
actually see containers as not only separation for humans, but
applications/tools as well. Isn't there alot of value in a tool being able
to access (for example) all Party information in a document by specifying the
container element (thereby accessing all of the Party information in one fell
swoop)? I see this as a definite plus for applications/tools, especially
from a performance standpoint.
Using XPath examples,
for instance one could access all Party element groups by specifying the
container element "PartyDetails":
/Header/PartyDetails
Or, the first Party
element group:
/Header/PartyDetails[1]
Or, the BuyerParty
element group:
/Header/PartyDetails/BuyerParty
Accessing
the entire "PartyDetails" group would allow an application that writes the
information to a database to cycle through all XParty subelements (where
X="Buyer", "Seller", etc.), and create database records for each of the XParty
subelements.
So, in
summary, I believe the containership approach is beneficial not only for human
consumption but machine consumption as well. I believe the benefits to the
containership approach far outweigh any potential
costs.
Kind
regards,
Joe
**************************************************************************
Joseph M. Chiusano
Logistics Management Institute
2000 Corporate Ridge
McLean, VA 22102
Email:
Tel: 571.633.7722
**************************************************************************
-----Original Message-----
From: Stuhec, Gunther
[mailto:]
Sent: Friday, August 23, 2002 3:39
AM
To: 'CHIUSANO, Joseph'; 'Gregory, Arofan';
'';
''
Subject: RE: [ubl-ndrsc] RE:
[ubl-lcsc] Newest version of the OO-design po sition
paper.
Hello Joe,
I do
not know, why we need this high-level containers like "Header, Summary, Party
etc.". This is a separation for humans, because all layouts of the hard copies
of business documents are divided in this strucute. But all (and really all)
XML instances will be processed by applications and tools only. Only the
designers, developers and support peoples are reading less XML instances
partially. Therefore, we have to think about which kind of "containers" and
"groups" are necessary and efficient for applications (not for
humans).
Kind
regards,
Gunther
-----Original Message-----
From: CHIUSANO, Joseph
[mailto:]
Sent: Donnerstag, 22. August 2002
19:13
To: Stuhec, Gunther; 'Gregory, Arofan';
'';
''
Subject: [ubl-ndrsc] RE: [ubl-lcsc]
Newest version of the OO-design position paper.
Hello,
Regarding CCTS
compliance: I don't recall anywhere in the CCTS v1.8 spec that mandates
the structure of XML documents in regard to Dictionary Entry Names (I could
have missed that detail, though). I believe that these are 2 separate
and distinct concepts.
In any event, I don't
believe the paper made a strong enough case for doing away with "good" (in my
opinion) structure principles (the container approach, as we call
it). Plus, I think it makes great sense to divide such documents into
high-level containers such as Header, Detail (or LineItem), and Summary,
I believe the arguments in the paper were weighted much too heavily on tools
and performance - and while always a valid concern, I don't believe that in
this day and age either should be a concern to this regard (that is, what
"harm" will a few additional containership tags do for performance). I
would personally like to see a much stronger case made for the proposed
approach.
Thanks for
listening.
Joe
**************************************************************************
Joseph M. Chiusano
Logistics Management Institute
2000 Corporate Ridge
McLean, VA 22102
Email:
Tel:
571.633.7722
**************************************************************************
-----Original Message-----
From: Stuhec, Gunther
[mailto:]
Sent: Thursday, August 22, 2002
12:08 PM
To: 'Gregory, Arofan'; '';
''
Subject: 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
