[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] [ADDITIONAL THOUGHT]Re: [regrep-cc-review] ASCCs/ASBIEs Revisited
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]