MHonArc v2.5.2 -->
ubl-ndrsc message
[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