[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components
Thanks Mark - Can you please forward to the UN/CEFACT Team? Joe "CRAWFORD, Mark" wrote: > > Joe, > > This seems a better question for the team responsible for the specification. > > Mark > > > -----Original Message----- > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > > Sent: Tuesday, August 05, 2003 10:05 AM > > To: CAM > > Cc: CCRev > > Subject: [regrep-cc-review] Core Components Issue: Representation of > > Aggregate Core Components > > > > > > CAM TC, > > > > For those who don't know me, I chair the "Core Components Review" > > subcommittee in the OASIS/Registry TC. We are in the midst of > > implementing the UN/CEFACT Core Components Technical Specification > > (CCTS) requirements in our registry architecture. > > > > We have a current issue that affects assembly of schemas from > > components > > that I would like to (on behalf of the subcommittee) run by you if I > > may. The bottom line issue is: If we derive an Aggregate Core > > Component > > (ACC) from another ("base") Aggregate Core Component, should > > the "base" > > and "derived" ACC each be a separate entity in the registry, with its > > own unique ID? Or should they be one entity with additional attributes > > added to it? If this isn't clear, the example below will clarify. > > > > Suppose we have an ACC called "Address. Details" - it > > contains the usual > > address information (street, city, etc.) We want to create > > several other > > "related" (derived) ACCs from this "base" ACC, and name them more > > specifically (i.e. with more semantic detail) - for example, > > "ResidenceAddress. Details", "OfficeAddress. Details", etc. > > > > Each of these "derived" ACCs would have the same properties > > and content > > as the "base" ACC - the only exception is their name. > > > > So the question is: If one wanted to assemble schemas using these > > derived ACCs, would it be more advantageous if they were > > represented as > > separate entities in the registry (i.e. separate from the "Address. > > Details" ACC) - thus with their own UUIDs? Or, would it be > > best to have > > a single "Address. Details" entity with each of its various "derived" > > names included as properties (these would be Slots according to the > > registry architecture). > > > > My viewpoint says it's best to represent them separately, so one could > > list the UUIDs for these entities in an "assembly template" > > (if that is > > the right term), and automatically "pick up" the right entity > > during the > > assembly process. The second approach would require some mechanism by > > which the proper Slot (name) could be identified in such a template. > > > > Please note also that with the first approach (separate entities), the > > "derived" ACCs would be associated with their "base" ACC > > through the use > > of registry associations. > > > > We appreciate your feedback very much. We want to ensure that our work > > takes into account all potential usage of the Registry down the road. > > > > Kind Regards, > > Joe Chiusano > >
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]