[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
Joe, > 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. > 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. - 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). - 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 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?? > 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!). Having all that, you can classify the BIEs (RegistryObjects). 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. Diego
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]