[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
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]