Subject: [Fwd: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components]
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
Title: FW: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components
- From: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
- To: "Regenald Kramer" <firstname.lastname@example.org>, "Fred van Blommestein (E-mail)" <email@example.com>, <firstname.lastname@example.org>
- Date: Tue, 5 Aug 2003 11:30:10 -0400Please keep Joe Chiusano (email@example.com) included as an addee on messages related to this topic.
From: Regenald Kramer [mailto:firstname.lastname@example.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
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
Group Manager B2B Standards Development & Maintenance
Rue Royale 145
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
From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: 05 August 2003 16:46
To: UN/CEFACT Core Component WG
Subject: FW: [regrep-cc-review] Core Components Issue: Representation of
Aggregate Core Components
See the discussion below. We owe an answer to the OASIS Registry CC Subteam on this.
From: Chiusano Joseph [mailto:email@example.com]
Sent: Tuesday, August 05, 2003 10:37 AM
To: CRAWFORD, Mark
Subject: Re: [regrep-cc-review] Core Components Issue: Representation of
Aggregate Core Components
Thanks Mark - Can you please forward to the UN/CEFACT Team?
"CRAWFORD, Mark" wrote:
> This seems a better question for the team responsible for the specification.
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:firstname.lastname@example.org]
> > 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:email@example.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard