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

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

Forwarded on behalf of Diego. Please see comments marked with <JMC2>.

Diego Ballvé wrote:
> 
> Hi,
> 
> Prefix is "diego3:" now.
> 
> Diego
> 
> > Forwarded on behalf of Diego. Please see comments below marked with
> > <JMC>.
> >
> > Diego Ballvé wrote:
> > >
> > > Joe,
> > >
> > > I have some points to raise about your example. See inline, prefixed
> > > with "diego2:".
> > >
> > > Diego
> > >
> > > > 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 Ballvé wrote:
> > > > >
> > > > > Important! Friday's deadline is here and we have to decide this:
> > > > >
> > > > > > > A) ASCC as RIM Association that "connects" two ACCs:
> > > > > >
> > > > > > <JMC>
> > > > > > 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.
> > > > > > </JMC>
> > > > >
> > > > > 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??
> > > >
> > > > <JMC>
> > > > 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").
> > >
> > > diego2: I think that according to CCTS you can't create another
> > > entity that way.
> >
> > <JMC>
> > 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?
> > </JMC>
> 
enough

<JMC2>
Sorry, I didn't understand this comment.
</JMC2>

> > 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?
> >
> > <JMC>
> > "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).
> > </JMC>
> 
diego3:
I checked section 6.1.4.1.4, CCTS 1.9 page 48, and there seems to be
no definition for a qualifier term for Core Component's Dictionary
Entry Name. It seems that you actually have different Object Classes,
followed by ". Details". So, they're ACCs. Can you identify other
differences??

<JMC2>
That's definitely an accurate assessment. Rising above the CCTS spec for
a moment: Do you feel that the scenario described above should involve
(a) the addition of an Object Class Qualifier (of "Residence" or
"Office"), or (b) the creation of a new Object Class ("ResidenceAddress"
or "OfficeAddress")? If we were to create a general guideline, do you
foresee all such scenarios involving (a) or (b)? Or a mix of the 2?
(sometimes (a) and sometimes (b))
</JMC2>
 
> The way I see it the possible "CCTS-ok" approaches are:
> 
> "schema construction template"
>   ACC #??0, "Top level. Details"
>     ASCC #??1, "TopLevel. OfficeAddress", (0..3), (ref #12345, ACC "OfficeAddress. Details")

<JMC2>
A few questions:

(1) Is it ok to call both "Address. Details" and "OfficeAddress.
Details" the same entity type (i.e. both ACCs)? Or, would there be value
in considering the "base entity" of "Address. Details" an ACC, and the
"derived entity" of "OfficeAddress. Details" a "QACC" (Qualified
Aggregate Core Component)? This approach would allow an "assembly"
product to ensure that it never instantiates the "base entity" in a
schema - only the "derived entities". Using two separate entity types
here would make this distinction clear. 

(2) Could the ASCCs here be simply represented as Associations, rather
than ExtrinsicObjects?
</JMC2>

>     ASCC #??2, "TopLevel. ResidenceAddress", (0..2), (ref #67890, ACC"ResidenceAddress. Details")
>     ...
> 
> OR
> 
> "schema construction template"
>   ACC #??0, "Top level. Details"
>     ASCC #??1, "TopLevel. Office. Address", (0..3), (ref #112233, ACC "Address. Details")
>     ASCC #??2, "TopLevel. Residence. Address", (0..2), (ref #112233, ACC "Address. Details")
>     ...
> 
> IMO, the same rules used to create ACC (ABIE!) are used to create
> the "schema construction template", which has 1 ACC as its
> top-level element. Either way the "references" are different (also
> in the registry). The "referenced" object, on the other hand, can
> be the same or not. I can't see the extra difficulties 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").
> >
> > <JMC>
> > 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?
> >
> > 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).
> >
> > Thoughts?
> > </JMC>
> 
 diego3:
 Except for the DictionaryEntryName, doesn't this "auto-update" happen
 naturally with our current approach for ASCCs?? You have to see ASCCs
 as references. Changes made to the referenced object (child ACC) will
 be available to the parent ACC automatically - because they are not
 stored with the parent ACC! There're only references to children CCs.

<JMC2>
I'm still not certain we have a current approach for ASCCs - I'm now
thinking in terms of "QACC and ASCC" where QACC is an ExtrinsicObject,
and ASCC is an Association. What are your thoughts on this?
</JMC2>
 
 In your example, since my parent ACC has only a reference (ASCC) to
 an (indirectly) contained ACC "Address. Details", "Country Code" BCC
 would be available immediately after added.

<JMC2>
Oh - I wasn't including ASCCs at all in my example above. I was thinking
in terms of the following:

- I have an ACC called "Address. Details"

- I want to create another ACC (which I call a "QACC" in the examples
above) called "OfficeAddress. Details"

- For purposes of this example, it does not matter whether "Office" is
considered an Object Class Qualifier, or "OfficeAddress" is considered a
new Object Class

Having said that, it appears that we have 2 possible choices for
representing this QACC:

(1) A "heavyweight" approach, in which an entirely new entity is
created, or 
(2) A "lightweight" approach, in which no new entity is created, but the
ACC (Address. Details) is updated to include "OfficeAddress" rather than
"Address"

It seems to me that (2) has some definite shortcomings - once we modify
the ACC, it cannot be used as a "base entity" for other ACCs. 

What are your thoughts?
</JMC2>

> 
> > > 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)
> > >
> > > diego2: We don't have cardinality for ACC ("Address. Details"). Only
> > > for BCC or ASCC - the 2nd can be viewed as ACC occurrence.
> > >
> > > > 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"???
> > >
> > > > 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.
> > > >
> > > > Thoughts?
> > > > </JMC>
> > > >
> > > > > Otherwise, we're specifying ASCC as ExtrinsicObject
> > > > >
> > > > > > > A) BCC as RIM Association that "connects" ACC to DataType:
> > > > > >
> > > > > > <JMC>
> > > > > > 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.
> > > > > > </JMC>
> > > > >
> > > > > Ok, that thought was flying to high and compromises
> > > > clarity. Drop it.
> > > > > We keep it simple and clear. BCC as ExtrinsicObject.
> > > > >
> > > > > Diego
> > > >
> >
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