OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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>

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>
 
> Regards,
> Diego
> 
>   ------------------------------------------------------------------------
>                                                        Name: figure7-1-newInterpretation-relationsOnly.jpg
>    figure7-1-newInterpretation-relationsOnly.jpg       Type: JPEG Image (image/jpeg)
>                                                    Encoding: base64
>                                                 Description: figure7-1-newInterpretation-relationsOnly.jpg
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]