Re: Figure 7.1 modified/no inheritance (was RE: [regrep-cc-review] BCC as RIM Association)

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

Please see comments below marked with <JMC>.

Diego Ballvé wrote:
> 
> > Please see comments below marked with <JMC>.
> >
> > Diego Ballvé wrote:
> > >
> > > > <JMC>
> > > > Yes - I am now more convinced (based on the excellent
> > information you
> > > > gave recently) that we really may need to represent ASCC as an
> > > > ExtrinsicObject rather than simply an Association with
> > Slots. And the
> > > > ASCC would itself be involved in 2 associations (to "join"
> > > > the ACCs that
> > > > it associates, as per p.12 example).
> > > > </JMC>
> > >
> > > Joe, I'm supporting ASCC as RIM Association! Read the mails I wrote
> > > this week.
> >
> > <JMC>
> > I'm not so sure that "ASCC as a RIM Association" is the best approach.
> > I'll expand on an response I gave to the e-mails you wrote this week:
> >
> > CCTS states that Stored Core Components have the following attributes:
> >       - Unique Identifier
> >       - Version
> >       - Dictionary Entry Name
> >       - Definition
> >       - Usage Rule
> >
> > My fundamental question is: Would an ASCC need to have
> > different values
> > for *at least one of the above attributes* than the BCC from
> > which it is
> > "derived"? In other words:
> >
> > - Is it possible that an ASCC may have a different Unique Identifier
> > than the BCC from which it is derived? I would say it must.
> > - Is it possible that an ASCC may have a different Version
> > than the BCC
> > from which it is derived? I would say it definitely may (i.e. we may
> > want to version ASCCs separately from A.
> >
> > ...and so on for Dictionary Entry Name, etc.
> >
> > Having said that:
> >
> > If we represent ASCCs with Associations, how would we handle the
> > scenarios I list above?
> > </JMC>
> 
> Exactly the same way as for ACC/BCC - and this is why we're insisting
> on it. This is what I meant when pointing out that Associations are
> RegistryObjects. It means that Associations have name, desccription
> and slots, just like ExtrinsicObject (although they do not have
> version - it would have to be a slot).

<JMC>
Please note that when I use the term "RegistryObject" I most often mean
"ExtrinsicObject" rather than "Association" - I always use the term
"Association" when I mean association.

I truly believe that we should represent the following entities are
RegistryObjects - meaning ExtrinsicObjects, not Associations: 
- BCCs
- ACCs
- BBIEs
- ABIEs
- Data Types
- CCTs
- Supplementary Components
- Supplementary Component Restrictions
- Content Component Restrictions

...and ASCCs as well. Any proposal to represent these as anything other
than ExtrinsicObjects will be considered, but it will have to be (a)
highly convincing (which I have not yet seen, to be quite honest), and
(b) done very soon - by the end of this week (Friday). 

Sorry to be so rigid about this, but it's for the best interest of the
effort so that we can keep moving forward.
</JMC>
 
> >
> > I was discussing with Farrukh about it and he supports that
> > > too. He asked for an UML diagram without inheritances cause it might
> > > be easier to see things, so I'm attaching it (with red
> > comments on how
> > > we map each "class"). Note that fields are hidden.
> > >
> > > Also, Farrukh has questioned the need for Associations
> > between objects
> > > when a Slot containing the UUID can be enough... see the attachment.
> >
> > <JMC>
> > I would welcome more details on this from Farrukh and/or yourself - my
> > thought is: Couldn't one *implement* an Association as a Slot
> > containing
> > the UUID of the Target Object? I would say yes. In other
> > words, without
> > additional background on this it sounds like we're getting into
> > implementation details here, beyond specification.
> > </JMC>
> 
> Not really. Slots, Associations and ExtrinsicObjecs are all part
> of Registry Specs. If we specify that X is binded to Association,
> somebody can *implement* it in any way he/she wants, although
> when you get that object from the registry (out of the
> implementation) using for instance SOAP interface and RIM/RS
> Schemas, you must get an Association. This allows that 2
> implementations can understand eachothers (be compatible).

<JMC>
Thanks for your thoughts - I completely understand what you are
proposing. However, I truly believe that the approach proposed here is
not only way too complex for the task at hand (i.e. why "bind X to an
Association" when we can simply prescribe use of an Association), it (in
my opinion) ignores the Association feature of the registry for (in my
opinion) no good reason. Please provide a stronger argument by the end
of Friday for this, so that we may consider this approach vs.
Associations.
</JMC>

> 
> 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