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: Re: [regrep-cc-review] Bringing It Home: BIEs, ASCCs, and BusinessContext

Chiusano Joseph wrote:

>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.


>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
>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.
>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

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