Re: [regrep-cc-review] Bringing It Home: BIEs, ASCCs, and BusinessContext

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

<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