UBL Naming and Design Rules SC

 View Only

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

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

    Posted 08-23-2002 09:51
     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
    >**************************************************************************
    >