ubl-ndrsc — archive

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

From: System
To: [email protected]
Date: Fri, 23 Aug 2002 09:51:00 -0000

 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.

From: "Michael C. Rawlins" <[email protected]>
To: "'[email protected]'" <[email protected]>
Date: Fri, 23 Aug 2002 08:50:46 -0500

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: [email protected]
>   Tel: 571.633.7722
>**************************************************************************
>