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

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

Forwarded on behalf of Diego. He clarifies his comment of "enough"
(reproduced below - please see original e-mail below for full context).

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

Diego says:

<Quote>
> Ops! I made a note during the 1st read through and forgot to
> expand it. That "enough" should be expanded to something like:
> 
> "Aren't the current specs enough for providing reusability of ACCs??"
</Quote>

Joe says: Can you please be more specific in your response? I'm not sure
that it answered the question I asked (at least from my interpretation).

Joe

Diego Ballvé wrote:
> 
> Ops! I made a note during the 1st read through and forgot to
> expand it. That "enough" should be expanded to something like:
> 
> "Aren't the current specs enough for providing reusability of ACCs??"
> 
> I really have to quit this discussion now. I'll get back to it later
> or tomorrow.
> 
> Diego
> 
> > 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