[ubl-lcsc] 8/25/2002: Newest version of the OO-design position paper.

[Monica Martin <mmartin@certivo.net>]

Joe brings up some valid points...and I would think that we may start to
think about higher-level business processess and entities that lead to
the generation of these XML structures and documents.  Those entities
may not be document centric but object, state, content and lifecycle
enabled to support document generation.  In that vein, the container is
really perhaps a representation of the entity (content, state, context
and identification of that business entity), such as "Order."
 
I am certain more discussion will follow.
 
Thanks.
Monica

	-----Original Message----- 
	From: Stuhec, Gunther 
	Sent: Fri 8/23/2002 1:38 AM 
	To: 'CHIUSANO, Joseph'; 'Gregory, Arofan';
'ubl-lcsc@lists.oasis-open.org'; 'ubl-ndrsc@lists.oasis-open.org' 
	Cc: 
	Subject: RE: [ubl-ndrsc] RE: [ubl-lcsc] Newest version of the
OO-design position 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:JCHIUSANO@lmi.org]
	Sent: Donnerstag, 22. August 2002 19:13
	To: Stuhec, Gunther; 'Gregory, Arofan';
'ubl-lcsc@lists.oasis-open.org'; 'ubl-ndrsc@lists.oasis-open.org'
	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: jchiusano@lmi.org 
	  Tel: 571.633.7722 
	
************************************************************************
** 

		-----Original Message-----
		From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com]
		Sent: Thursday, August 22, 2002 12:08 PM
		To: 'Gregory, Arofan'; 'ubl-lcsc@lists.oasis-open.org';
'ubl-ndrsc@lists.oasis-open.org'
		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:arofan.gregory@commerceone.com]
		Sent: Dienstag, 20. August 2002 23:20
		To: Stuhec, Gunther; 'ubl-lcsc@lists.oasis-open.org';
'ubl-ndrsc@lists.oasis-open.org'
		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:gunther.stuhec@sap.com] 
		Sent: Tuesday, August 20, 2002 1:57 PM 
		To: 'ubl-lcsc@lists.oasis-open.org';
'ubl-ndrsc@lists.oasis-open.org' 
		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