[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Fwd: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components]
Joe wrote - > Please bear in mind that the CCTS spec was written without the > participation/representation of anyone from the Registry TC, > and that we > have the freedom to deviate from the CCTS spec if we feel it would be > necessary to do so in our registry architecture. I also > anticipate that > there will be cases where we will do so - and we will clearly document > in both our Technical Note and our feedback to the CCTS Team > where such > deviations occur. Concur. However I hope that deviations are to support registry functionality/capabilities, rather than alter the relationship of the various entities defined in CCTS. Fred wrote <Quote1> > The CCTS does not support derivations of one ACC from > another, like the > derivation of a real ACC from an abstract ACC > </Quote1> and Joe Responded - > This is an example of something that we may feel is necessary in our > registry architecture - for example, our "Address. Details" > scenario in > which "Address. Details" may be considered an "abstract" > (base) ACC, and > "ResidenceAddress. Details" may be considered a "real" (derived) ACC > that can be re-used in multiple ACCs as needed. I don't agree with Fred, but would be careful with the concept of derivation. In your example you indicate there would be a ResidenceAddress.Details. I am not sure that would be the case. More likely there would be a Person. Residence. Address ASCC. Per rule [c24], Person. Residence. Address ASCC would have the properties of the Address. Details ACC. Fred Wrote - > <Quote3> > Another example is a "Buyer Party" that may be derived from a more > generic "Party". Though it is tempting to define a "Buyer Party" > as a special case of "Party", this can only be done "off-line", in the > discovery and harmonisation process. > </Quote3> Joe responded - > From the registry perspective: BuyerParty ("BuyerParty. > Details") is an > ABIE that is derived from an ACC called "Party. Details". This > "derivation" is done by classifying the "Party. Details" ACC according > to one of the 8 Context Categories (in this case, Business > Process Role) > and adding the proper Object Class Qualifier ("Buyer") to the ABIE. > > Regardless of at what stage this operation is done (discovery and > harmonization, some other process stage, etc.), we will need to have > this capability in the registry. Absolutely concur. Fred Wrote - > <Quote4> > The registry should not take such derivation into account. > </Quote4> And Joe responded - > This is a case where we will deviate - the registry must have this > capability. Concur. The registry must absolutely indicate where an ABIE is a derivation of an ACC. This is one of our basic concepts and is covered by the various storage rules in Section 7.3 and 7.4 Fred Wrote - > <Quote5> > Suppose later one adds some property to the "Buyer Party" and > not to the > "Party", or deletes a property. That would be allowed > according to CCTS > and consequently should be supported by the registry. > </Quote5> And Joe responded - > I agree with this completely - and I think it may contradict some > earlier comments. In any event, we will accomodate this by > the fact that > changes to the "Party" entity will automatically be reflected in the > "BuyerParty" entity. Concure that Fred is contradictory and Quote 5 is more reflective. However, I am somewhat concerned by the "will automatically be reflected in the "BuyerParty" entity statement. Since an ABIE of BuyerParty will be versioned, then how would one automatically create a new version? (from a business process and standards management perspective - not a technical perspective) Fred wrote - > <Quote6> > One BCC can never be the property of more than one ACC > </Quote6> And Joe responded - > This is another case where we will need to deviate - what > good is a BCC > if it can be used once and only once? Concur with Joe. There is not agreement within CCTS on Fred's position. Fred wrote - > <Quote7> > So BCC's and ASCC's are completely symmetrical. The registry should > consider both as properties of an ACC (with their own (U)uid's of > course). > </Quote7> Joe replied - > Focusing on the (U)uid's comment: Would it be advantageous for an ASCC > to have its own UUID in the registry? If we represent ASCCs with > Associations, is this possible? My understanding is that each type of CC and BIE (such as BCC, ACC, ASCC, & CCT) MUST have its own UUID. Mark C.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]