RE: [ubl-ndrsc] RE: [ubl-lcsc] Newest version of the OO-design position paper.

["Michael C. Rawlins" <mike@rawlinsecconsulting.com>]

I can see why these types of container elements might make it easier for an 
application to do that, but for the life of me I can't think of very many 
examples where this would really make a difference.   Buyer, Ship to, 
Carrier, etc., all probably go to very different database tables in most 
applications.  You also assume that the application which writes the data 
to a database is going to use XPath.  Some may, but most now aren't and 
won't any time soon.

There may be other reasons for container elements such as Header, but I 
don't see these as being very important.

Mike

At 07:58 AM 8/23/02 -0400, CHIUSANO, Joseph wrote:
>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: jchiusano@lmi.org
>   Tel: 571.633.7722
>**************************************************************************
>-----Original Message-----
>From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com]
>Sent: Friday, August 23, 2002 3:39 AM
>To: 'CHIUSANO, Joseph'; 'Gregory, Arofan'; 
>'ubl-lcsc@lists.oasis-open.org'; 'ubl-ndrsc@lists.oasis-open.org'
>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: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>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
>

---------------------------------------------------------------
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com