Re: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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