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: Core Components Issue: Representation of Aggregate Core Components


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
tel;work:(703) 902-6923
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
title:Senior Consultant
fn:Joseph M. Chiusano

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]