[Fwd: FW: [regrep-cc-review] Core Components Issue: Representation ofAggregate Core Components]

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

Team,

Keeping you all in the loop on our question that has been sent over to
the CCTS Team. Below, Alan Stitzer states (please note: the "ABIE" he
refers to is our "ResidenceAddress. Details" entity):

<Quote>
Since the ABIE is registered separately, it would, indeed have a
unique identifer separate from the Address. Details ACC.
</Quote>

In the next e-mail that I will forward, I asked Alan and Mark to clarify
whether "ResidenceAddress. Details" is indeed an ABIE - or perhaps some
"intermediate" entity between an ACC and ABIE.

Joe

---

• From: Alan.Stitzer@marsh.com
• To: uncefact-tmg-ccwg@listman.disa.org
• Date: Tue, 5 Aug 2003 10:57:33 -0400

It has been my impression that the base ACC, in this case Address. Details
would remain as an ACC that contains numerous properties relating to an
address, including things that you may not need for Residence Address.

Residence Address (or something like that) -- I don't want to worry about
the names right now, would have to be ABIE's which would restrict the ACC
Address. Details to the BCC's that you would like to see in Residence
Address.  Since the ABIE is registered separately, it would, indeed have a
unique identifer separate from the Address. Details ACC.

Since that is just my impression, I am hoping that someone else from the CC
team will respond and correct my impression if it is wrong...

Regards,


____________________
Alan Stitzer
AVP
Marsh USA Inc.
1133 Avenue of the Americas
New York, NY 10036-2774
Phone: (561) 743-1938
Fax: (561) 743-1993
Internet: Alan.Stitzer@marsh.com
____________________




<<< Memo from MCRAWFORD@lmi.org@Internet on 05 August, 2003, 10:48 Tuesday
>>>


MCRAWFORD@lmi.org@Internet on 5 Aug 2003, 10:48 Tuesday

Please respond to uncefact-tmg-ccwg@listman.disa.org@Internet

To:    uncefact-tmg-ccwg
cc:    chiusano joseph  (bcc: Alan Stitzer)
Subject:    FW: [regrep-cc-review] Core Components Issue: Representation of
       Aggregate Core Components


CCTS Team,

See the discussion below.  We owe an answer to the OASIS Registry CC
Subteam on this.

Mark


-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Tuesday, August 05, 2003 10:37 AM
To: CRAWFORD, Mark
Cc: CCRev
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
> >


---
You are currently subscribed to the uncefact-tmg-ccwg listserve.
To unsubscribe send an email to lyris@listman.disa.org with the
following subject: Unsubscribe uncefact-tmg-ccwg
If you do not receive confirmation of your unsubscribe request
please notify postmaster@disa.org to report the problem.



To:    uncefact-tmg-ccwg@listman.disa.org@Internet
cc:    chiusano_joseph@bah.com@Internet (bcc: CN=Alan
       Stitzer/OU=NYC-NY/OU=US/OU=Marsh/O=MMC)
From:  MCRAWFORD@lmi.org@Internet

---

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