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

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

<Quote1>
ps. I'm out-of-oasis till my CEO renew our membership. I guess I
still get mails but I can't mail the list.
</Quote1>

Sorry to hear that Diego - I hope you'll contain to provide feedback to
Farrukh and I, and I will copy the CC Review listserv on my replies to
you. Hope your membership is renewed soon - otherwise you could always
join as an individual member. :)

<Quote2>
should be **from the ACC it is "derived" from**, not BCC.
</Quote2>

Yes - thanks for the correction Diego.

<Quote3>
> the Object
> Qualifier. This could be viewed as an inefficient use of storage and
> difficult to maintain (would need to keep an ACC and ASCC in sync in
> terms of their attribute values).
Which attributes?? ASCC has businessTerm, which can differ from its
corresponding ACC's businessTerm (i.e Address, Residence Address,
Official Address). 
</Quote3>

ASCC has Business Term because it is "a particular category of Core
Components" [S17], which include a Business Term [S3]. [S17] also states
"stored Association Core Components shall include all Attributes of
stored Core Components.". That is the basis for my observation that we
would need to replicate attribute values between ACCs and ASCCs. Hope
that makes it clearer.

<Quote3>
Name?? Well, that you also have problems with BBIE, if you decide to
change parent ABIE's objectClass.
</Quote3>

I assume you mean Dictionary Entry Name. I want to make sure I address
your concern above: Suppose we have a BBIE called "US_Address. Street.
Text". It is contained within an ABIE called "US_Address. Details"
(Object Class is "US_Address"). If one decides to change the parent
ABIE's Object Class to "UK_Address", in my mind that change should
propagate to all BBIEs contained within the ABIE (we're into
implementation here, and beyond the specification). That should be the
function of a Registry user-facing tool that interacts with the Core
Components stored and maintained in the Registry. There should also be
another "trigger" that says that any time a part of a 11179 Data Element
Name (the 5 parts of Object Class Qualifier, Object Class, etc). changes
for any entity within the Registry (ex: Property Term changes on an
ACC), that change should automatically propagate back to the Dictionary
Entry Names for all entities whose Dictionary Entry Names depend on that
changed Data Element Name part.

So in summary, I don't think that anyone will "have problems", as long
as their implementation handles these scenarios properly. I am in the
process of putting together a document that details the actions that can
be taken by users in regards to Core Components (e.g. create a BIE from
an BCC, include an ACC within another ACC using an ASCC) and the order
in which they can happen, to see if there are any snags that we should
be aware of. Please stay tuned for this - it will take a few weeks.

Joe

Diego Ballvé wrote:
> 
> Chiusano Joseph wrote:
> 
> > <Quote2>
> > So I am leaning towards Association with Slots approach.
> > </Quote2>
> >
> > I am as well, but I'm keeping an open mind. Others? What are the
> > arguments in favor of not taking this approach? It seems to me that if
> > we represent ASCC as an ExtrinsicObject, we need to replicate the
> > attribute values from the BCC it is "derived" from, plus add
> 
> should be **from the ACC it is "derived" from**, not BCC.
> 
> > the Object
> > Qualifier. This could be viewed as an inefficient use of storage and
> > difficult to maintain (would need to keep an ACC and ASCC in sync in
> > terms of their attribute values).
> 
> Which attributes?? ASCC has businessTerm, which can differ from its
> corresponding ACC's businessTerm (i.e Address, Residence Address,
> Official Address). Name?? Well, that you also have problems with BBIE,
> if you decide to change parent ABIE's objectClass.
> 
> From another mail:
> 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)
> 
> Coming from an Association with Slots approach but not sure if that
> was the best and clearest approach to choose, regards,
> 
> Diego
> 
> ps. I'm out-of-oasis till my CEO renew our membership. I guess I
> still get mails but I can't mail the list.
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