Re: Feedback Due 9/5: Updated Requirements Mapping

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

Forwarded on behalf of Diego. Please see comments marked with <JMC2>.

Diego Ballvé wrote:
> 
> Chiusano Joseph wrote:
> > <JMC>
> > Not at all - reference [S2]: "Association Core Components will be
> > represented as Associations between ACCs, and will not be
> > considered as
> > "first rate" Core Components".
> > </JMC>
> >
> > If I have ASCC and I want to store them in the registry
> > can I still choose our mapping approach?? I hope so. I though
> > the point was to use RIM Association to represent it.
> >
> > <JMC>
> > Yes - see above.
> > </JMC>
> >
> > I propose again (if that is not what we're doing already!)
> > that we store
> > ASCC as RIM Association, use Association.name/Association.
> > description/Association's Slots to store CC/CCProperty details,
> > just like we do for BCC.
> >
> > <JMC>
> > Not sure what you mean by "to store CC/CCProperty details". An ASCC
> > Association will serve to associate 2 ACCs, and nothing more. CC
> > Properties will not be represented as entities in our architecture.
> > </JMC>
> 
> Great. No problems here then, I hope.
> I meant the fields that CCTS attributes to ASCC/ASCCProperty
> (i.e, ASCC.dictionaryEntryName, ASCCProperty.propertyTerm,..).

<JMC2>
We won't need such fields, since we will not be representing ASCCs as
entities but rather as Associations (so no dictionaryEntryName, no
propertyTerm, etc.). The CCTS spec is *much* too heavyweight on their
representations here - on top of ASCCs being entities, it also specifies
Association Core Component Properties (more entities!). Yikes!!!!

So we're getting rid of layers that do not need to exist.
</JMC2>

> Diego

Joe
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