No Subject

Regardless of at what stage this operation is done (discovery and
harmonization, some other process stage, etc.), we will need to have
this capability in the registry.

<Quote4>
The registry should not take such derivation into account.
</Quote4>

This is a case where we will deviate - the registry must have this
capability.

<Quote5>
Suppose later one adds some property to the "Buyer Party" and not to the
"Party", or deletes a property. That would be allowed according to CCTS
and consequently should be supported by the registry. 
</Quote5>

I agree with this completely - and I think it may contradict some
earlier comments. In any event, we will accomodate this by the fact that
changes to the "Party" entity will automatically be reflected in the
"BuyerParty" entity.

<Quote6>
One BCC can never be the property of more than one ACC
</Quote6>

This is another case where we will need to deviate - what good is a BCC
if it can be used once and only once?

<Quote7>
So BCC's and ASCC's are completely symmetrical. The registry should
consider both as properties of an ACC (with their own (U)uid's of
course). 
</Quote7>

Focusing on the (U)uid's comment: Would it be advantageous for an ASCC
to have its own UUID in the registry? If we represent ASCCs with
Associations, is this possible?

Thanks,
Joe
--------------C56FCC64C4F1FBBC55C97D32
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <f.van.blommestein@berenschot.com>
Received: from mclean-vscan1.bah.com ([156.80.3.61]) by
          mclean6-mail.usae.bah.com (Netscape Messaging Server 4.15) with
          ESMTP id HJ5T6400.GMS for <511251@mclean6-mail.usae.bah.com>;
          Tue, 5 Aug 2003 14:39:40 -0400 
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61])
	by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id h75IdNA20480
	for <511251@mclean6-mail.usae.bah.com>; Tue, 5 Aug 2003 14:39:23 -0400 (EDT)
Received: from extser-1.bah.com ([156.80.1.4])
 by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2003080514392332191
 for <511251@mclean6-mail.usae.bah.com>; Tue, 05 Aug 2003 14:39:23 -0400
Received: from w2k003.berenschot.com (w2k003.berenschot.com [62.58.36.243])
	by extser-1.bah.com (8.12.4/8.12.4) with ESMTP id h75Id8de001198
	for <chiusano_joseph@bah.com>; Tue, 5 Aug 2003 14:39:09 -0400 (EDT)
Received: from mailsrv01.berenschot.com ([10.249.2.108]) by w2k003.berenschot.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 20:38:23 +0200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Priority: normal
Importance: normal
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [regrep-cc-review] Core Components Issue: Representation of  Aggregate Core Components
Date: Tue, 5 Aug 2003 20:42:31 +0200
Message-ID: <CA4598A9AC972C4B80272D705FBAC0A843DF8A@MAILSRV01.berenschot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [regrep-cc-review] Core Components Issue: Representation of  Aggregate Core Components
Thread-Index: AcNbXvlMaZkzk9qDQRuu8QxtRjUuXQAAQS3AAAddgVs=
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: "UN/CEFACT Core Component WG" <uncefact-tmg-ccwg@listman.disa.org>
Cc: <chiusano_joseph@bah.com>, <kramer@ean-int.org>, <MCRAWFORD@lmi.org>
X-OriginalArrivalTime: 05 Aug 2003 18:38:23.0171 (UTC) FILETIME=[C0009130:01C35B80]

Joe, Mark, Regenald,
=20
My personal opinion on this subject:
=20
1. The CCTS does not support derivations of one ACC from another, like =
the derivation of a real ACC from an abstract ACC. The Address example =
is not that fortunate as such "derivation" can and probably will be =
solved by means of ASCC's. Another example is a "Buyer Party" that may =
be derived from a more generic "Party". Though it is tempting to define =
a "Buyer Party" as a special case of "Party", this can only be done =
"off-line", in the discovery and harmonisation process. The registry =
should not take such derivation into account. Suppose later one adds =
some property to the "Buyer Party" and not to the "Party", or deletes a =
property. That would be allowed according to CCTS and consequently =
should be supported by the registry.=20
=20
2. The UBL document Mark distributed states that the registry would not =
store "properties", but would store BCC's apart from ACC's and data =
types. A BCC is merely an association between an ACC and a data type, =
and has some attributes like Property Name and Cardinality. One BCC can =
never be the property of more than one ACC. Much like an ASCC, which is =
the association between two ACC's, again with attributes like Property =
Name and Cardinality. So BCC's and ASCC's are completely symmetrical. =
The registry should consider both as properties of an ACC (with their =
own (U)uid's of course).=20
=20
My two Eurocents.
=20
Fred
=20

	-----Original Message-----=20
	From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]=20
	Sent: Tue 8/5/2003 4:45 PM=20
	To: UN/CEFACT Core Component WG=20
	Cc: chiusano_joseph@bah.com=20
	Subject: FW: [regrep-cc-review] Core Components Issue: Representation =
of Aggregate Core Components
=09
=09

	CCTS Team,
=09
	See the discussion below.  We owe an answer to the OASIS Registry CC =
Subteam on this.
=09
	Mark
=09
=09
	-----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
=09
=09
	Thanks Mark - Can you please forward to the UN/CEFACT Team?
=09
	Joe
=09
	"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
	> >
=09


-------------=20
Dit e-mailbericht en enige bijlage is vertrouwelijk en=20
uitsluitend bestemd voor de geadresseerde(n). Indien u niet=20
de geadresseerde bent, mag u deze e-mail of enige bijlage niet=20
kopieren of aan derden ter inzage geven of verspreiden.=20
Indien u deze e-mail per vergissing heeft ontvangen=20
verzoeken wij u de afzender ervan onmiddellijk op de hoogte te=20
stellen per e-mail en de betreffende e-mail te vernietigen.

This e-mail and any attachment is confidential and may=20
contain legally privileged information. If you are not the=20
intended recipient, please note that this e-mail or any=20
attachment may not be copied or disclosed or distributed to=20
others. If you have received this e-mail by error, please notify=20
the sender immediately by return e-mail, and delete this message.=20
--------------=20


--------------C56FCC64C4F1FBBC55C97D32
Content-Type: text/x-vcard; charset=us-ascii;
 name="Chiusano_Joseph.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Joseph Chiusano
Content-Disposition: attachment;
 filename="Chiusano_Joseph.vcf"

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

--------------C56FCC64C4F1FBBC55C97D32--