[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Association Core Components - Represent withAssociations
<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:email@example.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard