Re: [regrep-cc-review] Association Core Components - Represent with Associations

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

<Quote1>
Ok.. just keep in mind that CCProperties are not stored independently.
Theiy are part of the referenced ASCC/BCC, meaning its attributes go
to wherever the ASCC/BCC attributes go. If ASCC is a RIM Association,
the Association will contain Slots with CCProperties attributes and
ASCC attributes.
</Quote1>

That's an excellent point, Diego. Thinking back to the "Core Component
Properties" entity (CCTS p.76) - it has the following attributes:

- Property Term
- Cardinality

In terms of the Data Element Name, the only difference between an ACC
and an ASCC is that the ASCC provides an Object Class Qualifier Term -
e.g. "Residence" for the Object Class "Address". So I believe the
Property Term would remain with the ACC, and not be placed with (or
repeated on) the ASCC.

In terms of Cardinality, I believe this would be a different case.
Suppose we had an ACC called "Address. Details", and 2 ASCCs (as in the
CCTS example we have been citing) that ultimate "resolve" to "Residence
Address" and "Official Address" (just using English terms here for
simplicity). One may want to assemble a schema from Core Components that
specifies a cardinality of (for example) "2" for Residence Address, and
"3" for Official Address (that not make sense, but let's pretend it does
for our purposes). If the Cardinality attribute were with the ACC, one
would not be able to make that distinction. So it appears then that the
Cardinality attribute should reside with the ASCC, so that this
distinction can be made.

How does that sound to you?

<Quote2>
I can then ask you why do we need BCC (which are similarly combined
with corresponding CCProperty) as ExtrinsicObjects, if they require
an Association to a DataType - and this RIM Association could contain
BCC + BCC Property attributes??? (I'm stretching it to the limit here)
</Quote2>

Another excellent point. My response would be that a BCC is the basic
stored block of information with which other "blocks" are combined
(using term loosely) to form the entities that ultimately reside in (for
our purposes) XML documents - BIEs and BBIEs. ASCCs are not fundamental
building blocks - they build *upon* another fundamental building block,
an ACC. So I view them as an extension of ACCs - they signify the role
that an ACC plays within an another ACC, and act as the "glue" that
joins 2 ACCs together.

Joe

Diego Ballvé wrote:
> 
> Chiusano Joseph wrote:
> >
> > <Quote1>
> > We agreed on not to add Slots to RIM Association for clarity
> > and I think
> > it makes sense.
> > </Quote1>
> >
> > Ah - I'm reconsidering here, in this context. :) I believe that this
> > approach was not good for Properties, but is good for ASCCs.
> 
> Ok.. just keep in mind that CCProperties are not stored independently.
> Theiy are part of the referenced ASCC/BCC, meaning its attributes go
> to wherever the ASCC/BCC attributes go. If ASCC is a RIM Association,
> the Association will contain Slots with CCProperties attributes and
> ASCC attributes.
> 
> I can then ask you why do we need BCC (which are similarly combined
> with corresponding CCProperty) as ExtrinsicObjects, if they require
> an Association to a DataType - and this RIM Association could contain
> BCC + BCC Property attributes??? (I'm stretching it to the limit here)
> 
> Probably the reason is clarity. Desired? Needed? That I can't answer
> alone.
> 
> Regards,
> Diego
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