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

[Monica Martin <monica.martin@sun.com>]

mm1: You know - following this <JMC>, <diego>, <diego2> and insertions 
is hard.....Anyway.....
Let's see if I survive the conversation.

Chiusano Joseph wrote:

>Forwarded on behalf of Diego. Please see comments below marked with
><JMC>.
>
>Diego: I have some points to raise about your example. See inline, prefixed
>with "diego2:".
>
>JMC: Forwarded on behalf of Diego, with comments below marked with <JMC>.
>Taking a step back and re-examining the notion of ASCCs, and
>considering
>introducing a new type of entity (QACC) not represented in the CCTS.
>
>Diego: Important! Friday's deadline is here and we have to decide this: A) ASCC as RIM Association that "connects" two ACCs:
>  
>
>>>>>Chiusano: I was also very comfortable with this, until recently where I realized the need to potentially represent ASCCs as RegistryObjects. One quick example is the "Version" attribute of Core Components - i.e. one may want to version an ASCC as its own entity. There are several other attributes of Core Components that follow in this vein, which I listed in a (this past) Friday e-mail. In my mind, this one is still open.  I can't give you strong arguments why ASCC should be represented as Association. IMHO it's just the natural way to see it considering its (ASCC's) function in the specs. What about other team members??
>>>>>Chiusano: I completely agree - that is how it struck me as well. Maybe we should take a step back here, and rethink this from scratch using the CCTS p.12 example. Let's say we already have an ACC in the registry called
>>>>>"Address. Details". Let's then say we want to create another entity (whose type is yet to be named for this example) from that ACC, and this entity represents "ResidenceAddress. Details" (i.e. we have
>>>>>given it an Object Class Qualifier of "Residence").
>>>>>          
>>>>>
>>Diego 2:I think that according to CCTS you can't create another entity that way. 
>>    
>>
>Chiusano: Yes, thanks - I agree. I think that this is something that is missing from the CCTS spec. I think it's natural for us to catch things that we may feel to be missing, since we are really specifying (relative to the
>CCTS spec) an "implementation" of the CCTS concepts. I'm thinking that the CCTS Team is looking to us to raise to them anything that we feel should be changed in the spec.
>
>With this in mind, do folks agree that it would be valuable to create an entity (a type of an ACC) in the registry called "ResidenceAddress. Details", that can be re-usable in many cases, thereby alleviating the
>need to constantly re-create it on-the-fly?
>
mm1: One impact you have to think about, and has been raised by CCSD, is 
if the ResidenceAddress. Details has the same attributes which supports 
the later discussion if it could also be an ABIE.

>
>The extension mechanism works by aggregation for CCTS (i.e., if we want ACC2 to "extend" ACC1 we must do ACC2
>contains ASCC2-1, which refers to ACC1).  Considering the example, if "ResidenceAddress. Details" is different
>than "Address. Details" (different content) then you have 2 ACCs. If not, then why do you need 2?
>  
>
>
>"ResidenceAddress. Details" will always be different than "Address.Details" because (at a minimum) it will have an Object Class Qualifier of "Residence". Let's think in terms of assembly: If we are assembling a schema from multiple entities, and we include the entities of "OfficeAddress. Details" and "ResidenceAddress. Details", would there be an advantage to having each of these entities represented as separate entities in the registry, and therefore having unique ID's? 
>
>It seems to me yes - i.e. I can "pull in" entity #12345 (OfficeAddress. Details) at a certain location in my "schema construction template", and entity #67890 (ResidenceAddress. Details) at another location in my schema construction template. Additionally, I can specify that (just for example purposes) entity #12345 occurs a maximum of 3 times, while
>entity #67890 occurs a maximum of 2 times. If these were not represented as separate entities in the registry, I believe this type of operation would be more difficult (i.e. we would be dealing with a single entity # for each - thus making it difficult to perform the operations described here).
> 
>  
>
>>>BUT: We do not yet have any notion of "joining" this entity with an ACC (such as Person. Details) - we want it to exist in the registry as "ResidenceAddress. Details", so that we can join it (include it in) in the future to whatever ACCs we choose.
>>>      
>>>
>>Diego2: If "we want it to exist in the registry as "ResidenceAddress. Details"", then it is an ACC (which might contain "Address. Details"). 
>>Chiusauno: That is the other issue here - apart from the above example where we have 2 separate entities (one for "OfficeAddress. Details", the other for "ResidenceAddress. Details"), what should their relation to the
>>"base entity" (Address. Details) be? Should they be "modified replicas" of the base entity (i.e. should they contain associations to all of the comprising BCCs), or should they be represented as ExtrinsicObjects that
>>simply have an Association ("derivedFrom") to the base entity? 
>>    
>>
mm1:  I would suggest the latter, primarily for the reason I gave in my 
response above.

>>In the second approach, any changes to the "base entity" would automatically be represented in the "derived entities" because the derived entities are associated with the base entity. In the first approach, the Associations of the derived entities to their comprising BCCs would need to be updated to keep in sync with those of the base
>>entity (ex: suppose we added a "Country Code" BCC to "Address. Details" that was not there before).
>>If you want to "join" 2 parts (ACC) with an ASCC you must have the 2
>>parts beforehand.
>>My question is: What type of an entity is "ResidenceAddress. Details" at the point at which it is created, and before it is included in any ACC?
>>
>>- It can't be an ASCC, because it has not (yet) performed the function that an ACC performs.
>>- It can't be an ABIE, because it does not have context per the 8 Context Categories (i.e. it is not US_ResidenceAddress. Details) - although it does have the context of "Residence".
>>- Can it be another ACC? (more below)
>>- Can it have a different Cardinality than that specified in the
>>"Address. Details" ACC? Absolutely - a "Residence Address" may have multiple occurrences within another entity, while an "Address" may have only a single occurrence.
>>BUT WAIT: Why would we want to specify Cardinality on "Address", when it is really meant to be an "abstract class" from which various types of Addresses are derived (and so it would never appear in an XML instance)?
>>
>>Perhaps we should not specify Cardinality on an ACC? (would apply to a BCC as well)
>>    
>>
mm1: I think this may be the logical alternative as we can't predispose 
what happens when the ACC is used (maps to conversation on assembly and 
context).
Thanks.

>>Diego2: We don't have cardinality for ACC ("Address. Details"). Only for BCC or ASCC - the 2nd can be viewed as ACC occurrence.
>>    
>>
>>>Chiusano: But what is "ResidenceAddress. Details" if it is not an ABIE or an ASCC?
>>>Is it an ACC?
>>>
>>>Or do we need an entirely new entity that is not specified in the CCTS - perhaps "QACC" (Qualified Aggregate Core Component -  pronounced "Quack")?
>>>      
>>>
>>diego2: If you really want to have "ResidenceAddress. Details" as a reusable entity (supposing that reusing "Address. Details" is not enough for you), can't you just create an ACC ("ResidenceAddress. Details") containing only 1 ASCC ("ResidenceAddress. Address"), referencing "Address. Details"???
>>    
>>
>>>Chiusano: Back to ASCC's: In light of this, I can see an ASCC being represented as an Association. Also, perhaps the Cardinality should be specified as a Slot on the Association that represents an ASCC.
>>>      
>>>
>>>>Otherwise, we're specifying ASCC as ExtrinsicObject 
>>>>
>>>>>>A) BCC as RIM Association that "connects" ACC to DataType:
>>>>>>            
>>>>>>
>>>>>I agree with Farrukh - I believe that BCC should be viewed as an entity, the most "basic" entity that we deal with in the Core Components methdology. IMO, if anything should be a RegistryObject, BCC should.
>>>>>          
>>>>>
>>>>Diego: Ok, that thought was flying to high and compromises clarity. Drop it.
>>>>        
>>>>
>>>>We keep it simple and clear. BCC as ExtrinsicObject.
>>>>        
>>>>