[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Bringing It Home: BIEs, ASCCs, and BusinessContext
<Quote> The only way I see the second form to make sense is if there are differences in the attributes of a OfficialAddress and a ResidenceAddress. </Quote> Absolutely - and I would assert that the only time such derived classes are created (in this case, ABIEs) are if there *are* differences in the attributes. For example, an ABIE called "WorkAddress" may include a BCC that represents a "MailStop", something that is not associated with residence addresses. I agree completely with Farrukh - if we allow registry users to simply copy ACCs and add Object Class Qualifiers while retaining all of the attributes of the "base" ACCs, a user could wind up with a maintenance nightmare. Joe Farrukh Najmi wrote: > > Chiusano Joseph wrote: > > >Team, > > > >Thinking about the example on p.12 of the CCTS, and how we see ASCCs > >created through the "Residence" and "Official" links: > > > >The CCTS spec does not explicitly acknowledge that one can have in a > >registry an entity named "ResidenceAddress. Details" or > >"OfficialAddress. Details" - > > > > On the issue of modeling ResidenceAddress Vs. OfficialAddress.... > > From a pure UML modeling stand point (always a good reference point for > me), I believe that the model should define exactly 1 type (Class) > called "PostalAddress". Then other types (such as Person or > Organization) may have separate attributes as follows: > > Class Person { > ... > PostalAddress residenceAddress; > PostalAddress officialAddress; > } > > I belive it will be wrong to model it as follows: > > Class Person { > ... > ResidenceAddress residenceAddress; > OfficialAddress officialAddress; > } > > The only way I see the second form to make sense is if there are > differences in the attributes of a OfficialAddress and a > ResidenceAddress. In that case I could see a base PostalAddress class be > used by two derived OfficialAddress and a ResidenceAddress classes and > the second form for class Person. > > -- > Farrukh > > >rather, it descibes the ASCCs that are > >created with these "links" in between. I am not saying that this was an > >omission in the CCTS spec, but I believe that from a registry standpoint > >the reality is that there is a great advantage to being able to > >register/derive and maintain entities named "ResidenceAddress. Details" > >and "OfficialAddress. Details" - so that they may be used in multiple > >ACCs. > > > >I propose then that: > > > >(1) We consider "ResidenceAddress. Details" amd "OfficialAddress. > >Details" to be ABIEs, even though they are not (to my knowledge) > >associated with one of the 8 context categories > > > >(2) We represent ASCCs as associations between these ABIEs and the ACC > >(per the p.12 example) in which they are contained > > > >So #1 means that a registry user can create an ABIE from an ACC *with > >classifying the ACC according to one the 8 context categories* - that > >is, by simply providing an Object Class Qualifier in the ABIE > >("Residence" or "Official"), in this case. > > > >It would be very inefficient (I believe) to require a user to reference > >a classification scheme every time they create an ABIE from an ACC - in > >the p.12 example, they would have to create a classification scheme with > >only 2 nodes ("Residence" or "Official") and then classify the ABIE. > >Much more complicated than it needs to be - the user should simply be > >able to add the Object Class Qualifier. > > > >The same concepts would apply for the BCC->BBIE transition - consider a > >case of "OfficeTelephoneNumber" (may include an extension) vs. > >"HomeTelephoneNumber" (would not include extension). > > > >Please provide thoughts on this. > > > >Thanks, > >Joe > > > >You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php > >
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]