OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[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]