OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[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]