[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [REVISITED AGAIN][regrep-cc-review] CCTS Spec RIM Mappings Revisited: [S8] to [S18]
Team, Here are requirements [S8] to [S18] revisted again, with our new approach (possibly experimental!) of omitting the notion of properties. Please see comments marked with <JMC>. Please offer comments on this proposed handling of these requirements. Thanks, 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> N/A, since we are not storing Core Component Properties as entities. </JMC> [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> N/A, since we are not storing Core Component Properties as entities. </JMC> [S10] Stored Core Component Properties shall include the following Attributes: - Property Term - Cardinality <JMC> Property Term and Cardinality will be represented as attributes of Basic Core Components (BCCs) and Association Core Components (ASCCs), through Slots. NOTE: For representation of Cardinality, see "Cardinality" thread. </JMC> 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> N/A, since we are not storing Core Component Properties as entities. </JMC> [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> N/A, since we are not storing Core Component Properties as entities. This linkage will now be directly from a Data Type to a BCC. </JMC> 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> N/A, since we are not storing Core Component Properties as entities. </JMC> [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> N/A, since we are not storing Core Component Properties as entities. </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> N/A, since we are not storing Core Component Properties as entities. </JMC> [S16] Stored Basic Core Components shall represent a Basic Core Component Property of a particular Aggregate Core Component. <JMC> N/A, since we are not storing Core Component Properties as entities. However, we will represent the relationship between ACCs and BCCs through Associations. </JMC> 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> We will simply include all attributes of Core Components with the Association Core Component (ASCC) ObjectType. </JMC> [S18] Stored Association Core Components shall represent an Association Core Component Property of a particular Aggregate Core Component. <JMC> N/A, since we are not storing Core Component Properties as entities. However, we will represent the relationship between ACCs and ASCCs through Associations. </JMC> THE END. 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> > > [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> > > [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> > > 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> > > [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> > > 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> > > [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> > > 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> > > ------------------------------------------------------------------------ > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
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]