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: No Subject


[S8] Stored Core Component Properties shall be stored as part of the
stored Aggregate Core Component to which they belong, i.e. they shall
never exist independently of their owning Aggregate Core Component.

<JMC2> 
Thanks - but since we're not representing Core Component Properties as
entities, I believe this would be a moot point. This would follow for
the rest of your comments below, up to and including "Same can be seen
graphically..." (so sorry!).
</JMC2>
 
[S12] Stored Basic Core Component Properties shall be linked to the Data
Type that describes the possible values of the Basic Core Component
Property.

[S16] Stored Basic Core Components shall represent a Basic Core
Component Property of a particular Aggregate Core Component.

--> a BCC has an 1 to 1 relation to a BasicCCProperty which is part of
1 and only 1 ACC.

Same can be seen graphically in well-known Figure 7-1, page 75.

Being open-minded now, maybe this restriction is not the best thing.
For instance, if I want to reuse a BCC currently I have to pack it
inside an ACC and reuse the ACC. Extra work, extra logic, extra space.

<JMC2>
Yes - I completely agree!
</JMC2>
 
It would also create new problems. Where would the BCC name came from?
By itself BCC does not have an Object Class Term, nor a Property Term.
Maybe a basic type..

<JMC2>
BCCs have a Property Term - we've moved Property Term from Core
Component Properties (p.77 top) to BCCs. So for example, a BCC may be
named "TelephoneNumber" where "Telephone" is the Property Term.
</JMC2>
 
Besides, we can say that we support reusing BCCs in the registry (if
we specify it) but CCTS doesn't take advantage of this feature unless
it gets changed.

<JMC2>
I agree - and I think it's highly important for us to support this. So
for example, the BCC of "TelephoneNumber" should be able to appear in
multiple ACCs, because it is - by nature - so "highly reusable".
</JMC2>

> 
> >
> > >
> > > >, and have a different Cardinality in each
> > > > occurrence (i.e. why restrict it to the same maximum
> > occurrences for
> > > > every scenario?)
> > > >
> > > > In light of that, I wonder if it would be best to specify the
> > > > Cardinality along with the Association between the ACC
> > and the BCC,
> > > > rather than on the BCC itself.
> >
--------------B6A33896F2F74DB36891375F
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

--------------B6A33896F2F74DB36891375F--



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