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

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

Team,

Here is another comment from Fred van Blommestein of the CCTS Team. He
states:

<Quote>
Even the CCTS itself gives the answer: Residence or Official or even
Office address are separate and unique ASCCs with separate "own" UUIDs
belonging to other ACCs, right?! e.g. Person. Residence. Address  
</Quote>

My additional note for us: We are currently considering whether we
should call "Residence" and "Official" ASCCs, because they can stand on
their own within the registry as entities themselves (i.e. they don't
always have to have an association in the registry to another ACC). It
seems to me that the "Person. Details" ACC (CCTS p.12 example) can
itself be included in another ACC - i.e. it would not normally be the
top entity of an XML document. 

So, should we call "Person. Details" an "ACC" in one case (when it is
not included in another ACC), and an "ASCC" in another? I would so no -
it is really the same entity regardless of whether it stands on its own
as the top-level entity of an XML document, or it is included within
another ACC. So why should we treat "ResidenceAddress. Details" and
"OfficeAddress. Details" any differently? Why not call these "ABIEs" (if
indeed they are), or "QACCs" (Qualified Aggregate Core Components).

Thoughts?

Joe

---

• From: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
• To: "Regenald Kramer" <kramer@ean-int.org>, "Fred van Blommestein (E-mail)" <f.van.blommestein@berenschot.com>, <chiusano_joseph@bah.com>
• Date: Tue, 5 Aug 2003 11:30:10 -0400

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

Please keep Joe Chiusano (chiusano_joseph@bah.com) included as an addee on messages related to this topic.

 

Mark
-----Original Message-----
From: Regenald Kramer [mailto:kramer@ean-int.org]
Sent: Tuesday, August 05, 2003 11:04 AM
To: Fred van Blommestein (E-mail)
Cc: CRAWFORD, Mark; UN/CEFACT TBG17 - Harmonization; Frank van Damme (E-mail); Coen Janssen (E-mail)
Subject: FW: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components

Fred,

With our findings from London, can you reply on behalf of TBG 17 and CCSD? Besides this, the example is about address. details, one of your favourite ACCs!

Even the CCTS itself gives the answer: Residence or Official or even Office address are separate and unique ASCCs with separate "own" UUIDs belonging to other ACCs, right?! e.g. Person. Residence. Address 

Cheers,

Regenald Kramer

Group Manager B2B Standards Development & Maintenance
EAN International
Rue Royale 145
B-1000 Brussels
Belgium
tel. +32.2.227.5440
fax +32.2.227.1021

e-mail: kramer@ean-int.org
website: www.ean-int.org

GSMP: the engine that powers the EAN.UCC System

one mission, one organisation

CONFIDENTIALITY/DISCLAIMER: The contents of this e-mail are confidential and are not regarded as a contractual offer or acceptance from EAN International, (registered in Belgium). If you are not the addressee, or if this has been copied or sent to you in error, you must not use data herein for any purpose, you must delete it and should inform the sender. EAN International disclaims liability for accuracy or completeness, and opinions expressed are those of the author alone. EAN International may monitor communications. Third party rights acknowledged. ©2003

-----Original Message-----
From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: 05 August 2003 16:46
To: UN/CEFACT Core Component WG
Cc: chiusano_joseph@bah.com
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
> >

---

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