[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] CCTS Spec RIM Mappings Revisited: [S8] to [S18]
<Quote1> I still think that Properties should be stored as RIM Associations between an Aggregate and its children (Basic/Association). </Quote1> I don't believe that RIM Associations would be able to hold the attributes required for CC Properties (Property Term and Cardinality). <Quote2> Sustaining the Associaton approach for Properties, you have no ObjectType for them - ObjectType is Association. </Quote2> Hmmm...I wonder if treating Associations as Objects (even though they are RegistryObjects) could potentially be confusing. <Quote3> Is it said anywhere that a Core Component is, by default, a Basic Core Component or is it your/our convention? I'm not aware of it. </Quote3> This is just my convention (my way of thinking of it). Another way to put it is that CCTS uses the term "Core Component" as a general term, and we know that there are 2 types of CCs - BCCs and ACCs. So, if a Core Component is not an ACC, it must be a BCC. Thanks, Joe Diego Ballvé wrote: > > Comments inline tagged by <Diego>. > > Regards, > Diego > > > Chiusano Joseph wrote: > > > > Team, > > > > We had put requirements [S8] to [S18] on hold pending > > clarifications on > > Properties and Data Types. Now that we have a better understanding of > > these entities, I'd like to revisit these requirements - please see > > below. > > > > The biggest question I have is whether we need to store both an entity > > (such as a BCC) and its Properties, or if its "Properties" are simply > > another way of viewing the entity. > > > > Thanks in advance for your feedback. > > > > Joe > > > > p.76: > > > > 7.1.3 Stored Core Component Properties > > > > [S8] > > Stored Core Component Properties shall be stored as part of the stored > > Aggregate Core Component to which they belong, i.e. they shall never > > exist independently of their owning Aggregate Core Component. > > > > <JMC> > > We can represent the relationship between ACCs and Core Component > > Properties through Associations. > > > > QUESTION: Do we need to represent BCC Properties and BCCs as separate > > entities in the registry? According to Figure 7-1 (p.75), they are > > separate entities. Or, are these just 2 different ways of looking at a > > BCC? > > </JMC> > > <Diego> > Hard to decide. Are they the same? IMO no. While BCC defines a concept, > Property aggregates it to a bigger concept. Associates it to a bigger > concept... -> Association!! > > Property defines: > - a name for the Aggregate to identify the aggregated part; > - a type for the aggregated part (i.e., Name BCC in Person. Details) > - cardinalities for the aggregated part. > > I still think that Properties should be stored as RIM Associations > between an Aggregate and its children (Basic/Association). > </Diego> > > > [S9] > > Stored Core Component Properties shall be defined as one of the two > > recognized types: Basic Core Component Property or Association Core > > Component Property. > > > > <JMC> > > We can represent this through the "ObjectType" classification of > > RegistryObjects. > > </JMC> > > <Diego> > Sustaining the Associaton approach for Properties, you have no > ObjectType for them - ObjectType is Association. > > You don't need to difer between Basic and Association Properties. > You can simply check if the target is a Basic or an Association CC. > Although Figure 7-1 (p.75) shows BasicProperty related to DataType, > there is a 1 to 1 relationship from BasicProperty to BCC. IMO, > DataType can be directly related to BCC. Same for Association > Propert, ASCC and its ACC. (This was just to show that Property > types can actually be seen as equal types). > </Diego> > > > [S10] > > Stored Core Component Properties shall include the following > > Attributes: > > - Property Term > > - Cardinality > > > > <JMC> > > Property Term - represent using a Slot > > Cardinality - represent using a Slot that indicates the maximum number > > of occurrences of the Core Component Property (like W3C Schema's > > "maxOccurs" facet). > > > > QUESTION: How should we represent "mandatory/optional" for attributes, > > as specified in the CCTS? We could have "minOccurs" and "maxOccurs" > > Slots for all entities, in which: > > > > (0,1) indicates optional (i.e. minOccurs="0", maxOccurs="1"); > > (1,1) indicates mandatory; > > (0,r) indicates optional, repetitive > > (1,r) indicates mandatory, repetitive > > > > This approach would allow us to represent both the optional/mandatory > > characteristic and cardinality characteristic for a given entity using > > the same set of attributes. > > </JMC> > > <Diego> > Please check mail in new thread "Cardinality". > </Diego> > > > p.76: > > > > 7.1.4 Stored Basic Core Component Properties > > > > [S11] > > Basic Core Component Properties are a particular category of Core > > Component Properties. As such, stored Basic Core Component Properties > > shall include all Attributes of stored Core Component Properties. > > > > <JMC> > > This is handled by the fact that a Core Component is, by default, a > > Basic Core Component - otherwise it is an Aggregate Core Component. > > Therefore, a Core Component Property is, by default, a Basic Core > > Component Property - otherwise it is an Aggregate Core Component > > Property (i.e. this is simply a matter of semantics). No RIM update > > required. > > </JMC> > > <Diego> > Is it said anywhere that a Core Component is, by default, a Basic Core > Component or is it your/our convention? I'm not aware of it. > > Anyway, +1 on it not being a problem. :) > </Diego> > > > [S12] > > Stored Basic Core Component Properties shall be linked to the > > Data Type > > that describes the possible values of the Basic Core > > Component Property. > > > > <JMC> > > It appears that Data Types should be represented as > > RegistryObjects (see > > [S27], p.79). Having said this, we can "link" a BCC Property > > to its Data > > Type using an Association. > > </JMC> > > <Diego> > Yep. Data Types are required. But this req does not say "directly > linked". So I suppose it's ok to link it indirectly, through BCC. > </Diego> > > > 7.1.5 Stored Association Core Component Properties > > > > [S13] > > Association Core Component Properties are a particular > > category of Core > > Component Properties. As such, stored Association Core Component > > Properties shall include all Attributes of stored Core Component > > Properties. > > > > <JMC> > > We can represent this in the registry through a "derivation" mechanism > > that indicates that ASCC Properties are derived from CC > > Properties (i.e. > > they contain all of the attributes of CC Properties). We can use a > > "Derived From" association. > > </JMC> > > <Diego> > I still don't get the inheritance need here. I don't think you need > to associate a ASCC Property to a CC Property in the registry. No > needo for Association, IMO. CC Property is abstract and doesn't get > stored. Only Basic or Associated properties. Although, they are both > CC Properties - inherit from CC Property. > </Diego> > > > [S14] > > Stored Association Core Component Properties shall be linked to the > > Aggregate Core Component that describes the structure of the > > Association > > Core Component Property. > > > > <JMC> > > In context of the example on p.12 of CCTS, this would roughly read: > > "ASCC 'Residence' has properties Address. Street. Text, Address. Post > > Code. Text, etc.; these properties shall be linked to ACC > > 'AddressDetails'". > > > > We can represent this as an Association between the ASCC > > (Residence) and > > the ACC (Address. Details). > > </JMC> > > > > 7.1.6 Stored Basic Core Components > > > > [S15] > > Basic Core Components are a particular category of Core Components. As > > such, stored Basic Core Components shall include all Attributes of > > stored Core Components. > > > > <JMC> > > Same as [S11]: This is handled by the fact that a Core > > Component is, by > > default, a Basic Core Component - otherwise it is an Aggregate Core > > Component (i.e. this is simply a matter of semantics). No RIM update > > required. > > </JMC> > > > > [S16] > > Stored Basic Core Components shall represent a Basic Core Component > > Property of a particular Aggregate Core Component. > > > > <JMC> > > Similar to [S8]: We can represent the relationship between > > ACCs and BCCs > > through Associations. > > </JMC> > > <Diego> > +1, the Association being the Basic CC Property. > </Diego> > > > 7.1.7 Stored Association Core Components > > > > [S17] > > Association Core Components are a particular category of Core > > Components. As such, stored Association Core Components shall include > > all Attributes of stored Core Components. > > > > <JMC> > > Similar to [S13] which addresses ACC Properties: We can represent this > > in the registry through a "derivation" mechanism that indicates that > > ASCCs are derived from CCs (i.e. they contain all of the attributes of > > CCs). We can use a "Derived From" association. > > </JMC> > > > > [S18] > > Stored Association Core Components shall represent an Association Core > > Component Property of a particular Aggregate Core Component. > > > > <JMC> > > Similar to [S8] and [S16]: We can represent the relationship between > > ACCs and ASCCs through Associations. > > </JMC> > > <Diego> > +1, the Association being the Association CC Property. > </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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]