[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-ndrsc] RE: [ubl-lcsc] Newest version of the OO-design position paper.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC