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: "CHIUSANO, Joseph" <>
To: "'Stuhec, Gunther'" <>,"CHIUSANO, Joseph" <>,"'Gregory, Arofan'" <>,"''" <>,"''" <>
Date: Fri, 23 Aug 2002 07:58:21 -0400
Title: RE: [ubl-lcsc] Newest version of the OO-design position paper.
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:
Tel: 571.633.7722
**************************************************************************
