Re: [regrep-cc-review] [ADDITIONAL THOUGHT]Re: [regrep-cc-review] ASCCs/ASBIEs Revisited

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

Please see 2 comments marked with <JMC2>.

Diego Ballvé wrote:
> 
> > > Regarding CCTS spec p.12, example: Another way to view the "Address.
> > > Details" ACC is as an abstract class which cannot be instantiated, but
> > > which can be used to derive sub-classes. More specifically, "Address.
> > > Details" would never appear in an XML document, but "Person. Residence.
> > > Address" (for which "Residence" can be considered a sub-class derived
> > > from "Address. Details") would appear.
> >
> > Nice way to see it. I agree with all but the fact that an ACC cannot be
> > instantiated at all. If you assemble a form, the form itself can be
> > viewed as an ACC, composed by ASCCs and BCCs.
> 
> <JMC>
> Both our perspectives here are superceded by Mark Crawford's
> clarification earlier today: "CCs (BCC, ACC, ASCC) will NEVER be used to
> create an instance document.  Only BIEs."
> </JMC>
> 
> <Diego>
> Sorry for not been clear. What I had in mind was that the top-most ABIE
> in a form, which is not an ASBIE, maps to a top-most ACC. So, yes, it
> does not get instantiated. Instead, one of its extensions does. This will
> come back later when we move to BIEs.
> </Diego>
> 
> >
> > > So we could potentially have many ASCCs in a registry derived from the
> > > "Address. Details" ACC.
> >
> > Definitely.
> >
> > > It appears that the transition from ACC to ABIE occurs when business
> > > context is added, and that business context is one of the 8 predefined
> > > context categories (Business Process, Product Classification, etc.).
> > >
> > > It appears that the transition from ACC to ASCC occurs when business
> > > context is added, but that business context is NOT one of the 8
> > > predefined context categories. The same holds true for the transition
> > > from ABIE to ASBIE - except that an ASBIE already incorporates one of
> > > the 8 predefined context categories (by virtue of the fact that we are
> > > starting with an ABIE).
> >
> > Agree on both.
> >
> > > I think we can represent ASCCs (created from ACCs) and ASBIEs (created
> > > from ABIEs) with registry associations,
> >
> > I was voting for this approach but I have some doubts now.
> > - First, Association is a RegistryObject but not a RegistryEntry. So you
> > loose status and version control capabilities from RIM.
> 
> <JMC>
> True - but I'm not sure what that is undesirable - i.e. why an
> Association should be that "heavyweight". Taking the RegistryEntry
> attributes one-by-one, and considering them in light of Associations:
> 
> expiration:
>         - Is there value in having an expirationDate for an                     Association?
> majorVersion:
>         - Is there value in having multiple versions of an Association?                 To
> me, it seems that either an Association exists, or it           doesn't.
> minorVersion:
>         - See "majorVersion"
> stability:
>         - Relates to content; do Associations really have "content"?
> userVersion
>         - See "majorVersion"
> </JMC>
> 
> <Diego>
> I don't want to change Associations! I'm happy with them. :)
> This comments were for the approach that there would be no RegistryObject
> (ExtrinsicObject) specific for an ASCC. Just an Association between 2 ACCs.
> That's not what you're talking about. Cleared.
> </Diego>

<JMC2>
Hmmm...I was thinking along the lines of representing ASCCs as
RegistryObjects. If they are represented only as an Association between
2 ACCs, how would we represent the name of the ASCC? For example, if we
have 2 ACCs called "Person. Details" and "Address. Details", and an ASCC
"between them" called "Residence", where would we put the name
"Residence"? We could add a Slot to the Association for this, but it
seems a bit sloppy. What do you think?
</JMC2>

> > - Second, since you don't have an ExtrinsicObject you can't set your own
> > objectType attribute (ASCC/ASBIE in this case, although you can set
> > associationType).
> 
> <JMC>
> I think your last point regarding associationType is 100% correct - we
> could have an associationType of (for example) "Derives From".
> </JMC>
> 
> > - Third, in the attached document you've made the following note:
> > "*Note that the relationship between the "Person. Details" ACC and the
> > "Residence" ASCC can also be represented with a registry association.
> > So there are really 2 associations here."
> >
> > How are you seeing this 2 Associations??? Like this?
> > Person. Details ACC (Contains) Residence ASCC (Extends) Address. Details
> 
> <JMC>
> Exactly. I should have stated that in the document - will update.
> </JMC>
> 
> > But since an Association needs a source and a target, Residence ASCC
> > must be a RegistryObject. would we have an Association as source/target
> > of another??
> 
> <JMC>
> Exactly. Residence ASCC would be a RegistryObject, with an Association
> to the "Address. Details" ACC, and another Association to the "Person.
> Details" ACC (I'm not being specific about the Association direction
> here - just talking high-level).
> 
> If we feel the registry is becoming "heavy" with all these
> RegistryObjects, there is an alternative for the Residence ASCC - for
> example, it could be represented with a Slot on the "Address. Details"
> ACC RegistryObject. However, this approach hits a brick wall when we
> have to "join" the Residence ACC (represented as a Slot on the "Address.
> Details" ACC RegistryObject) to the "Person. Details" ACC. With multiple
> Slots on the "Address. Details" ACC - each representing an ASCC - how
> would we indicate which Slot is participating in the Association? So
> there may be no better way than representing these ACCs and ASCC as
> RegistryObjects.
> </JMC>
> 
> >
> > > while the transition from ACCs
> > > to ABIEs can be represented by classifications (per the 8 context
> > > categories). The path from ACC to ASBIE will therefore use both
> > > associations and classifications - the order of which depends on whether
> > > the path was:
> > >
> > > ACC --> ABIE (classification) --> ASBIE (association)
> > >
> > > OR
> > >
> > > ACC --> ASCC (association) --> ASBIE (classification)
> >
> > Classification can (only) be made based on a ClassificationScheme.
> > I see it so that if you have 8 predefined context categories, then you
> > have 8 ClassificationSchemes (containing all the posible classification
> > nodes!).
> 
> <JMC>
> Yes.
> </JMC>
> 
> Having all that, you can classify the BIEs (RegistryObjects).
> 
> <JMC>
> Yes.
> </JMC>
> 
> > But you still need 2 RegistryObjects (1 CC and 1 BIE) and 1 Association
> > between them.
> >
> > Said that, I didn't get the point for the 2 paths.
> 
> <JMC>
> What, you mean you can't read my mind? ;) I should have been clearer:
> 
> I believe there are 4 possible "transitions" involving ACCs, ASCCs,
> ABIEs, and ASBIEs:
> 
> (1) ACC  --> ABIE
> (2) ABIE --> ASBIE
> (3) ACC  --> ASCC
> (4) ASCC --> ASBIE
> 
> That is, a Registry user should be able to "convert" an ACC to an ABIE
> (case #1), an ABIE to an ASBIE (case #2), etc.
> 
> I obtained this list by considering all 12 possibilities (assuming X -->
> X was not valid - such as ACC --> ACC), and negating the ones that did
> not make sense. For example, the following did not make sense:
> 
> ASCC  --> ABIE
> ASBIE --> ACC
> etc.
> 
> Having said that, the path from an ACC (the most generic entity) to an
> ASBIE (the least generic entity) could be gotten two ways:
> 
> Join (1) and (2): ACC --> ABIE --> ASBIE
> Join (3) and (4): ACC --> ASCC --> ASBIE
> 
> Lastly, we can use classification and association as follows:
> 
> ACC --> ABIE (classification) --> ASBIE (association)
> ACC --> ASCC (association) --> ASBIE (classification)
> 
> Please let me know if you think this makes sense.
> </JMC>
> 
> <Diego>
> Yep, makes sense. I'd like to point that the "conversion" is made by
> a tool. We (or the Registry) just have to care about how to store the
> results of the conversion, and how to offer proper ways to navigate
> through it (ExtrinsicObjects for CCs and for BIEs, Associations and
> Classifications -> the paths that you're describing).
> </Diego>

<JMC2>
Absolutely.
</JMC2>
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