Re: [regrep-cc-review] CCTS Spec RIM Mappings (7.1.1-7.1.2)

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Please see comments inline marked [JMC2] for [S4]-on.

Diego Ballvé wrote:
> 
> Comments below, prefixed by [Diego].
> 
> Diego
> 
> > p.75:
> >
> > 7.1.1 Stored Core Components
> >
> > [S1]
> > - Unique Identifier
> >
> > [JMC] Defer to existing RIM spec: UUID assigned to RegistryObject. No
> > updates necessary for CC.
> >
> > - Version
> >
> > [JMC] Defer to existing RIM spec: "MajorVersion" and "MinorVersion"
> > RegistryEntry attributes. No updates necessary for CC.
> >
> > - Dictionary Entry Name (already covered: RegistryObject.name)
> > - Definition (already covered: RegistryObject.description)
> >
> > - Usage Rule: See p.65 Section 6.2.4
> >
> > [JMC] Out of our scope, as it references Section 6 (we are verifying
> > Section 7). Sidenote: Section 6 will most likely be covered by OASIS
> > CAM.
> >
> > p.76:
> >
> > [S2]
> > Stored Core Components shall always be defined as one of the 4
> > recognized types: Basic Core Component (p.77 Section 7.1.6),
> > Association
> > Core Component (p.77 Section 7.1.7), Aggregate Core Component (p.76
> > Section 7.1.2), or Core Component Type (p.77 Section 7.1.8)
> >
> > [JMC] Use "ObjectType" RegistryObject attribute. Augment existing list
> > of Pre-defined object types. More details to be discussed at a later
> > point.
> >
> > [JMC] Association Core Component probably not needed - will represent
> > this functionality using the existing registry Association mechanism.
> >
> > [S3]
> > - Business Term
> >
> > [JMC] Use Slot mechanism (i.e. not mappable to existing RIM).
> 
> [Diego] +1 with Joe's statements for [S1-S3]
> 
> > 7.1.2 Stored Aggregate Core Components
> >
> > [S4]
> > Aggregate Core Components are a particular category of Core
> > Components.
> > As such, stored Aggregate Core Components shall include all Attributes
> > of Stored Core Components.
> >
> > [JMC] Should we consider introducing some type of inheritance
> > mechanism
> > in the registry, perhaps by introducing an "InheritsFrom" association
> > and specifying that any updates made to a RegistryObject that is the
> > source of this association must propagate to the target
> > RegistryObject?
> 
> [Diego] I don't get it. Why would you need it here? You are not storing
> a CoreComponent and an AggregateCoreComponent, just 1 ACC. So no need
> for inheritance here. Correct?>

[JMC2] Correct - I was thinking CC-BIE here instead of ACC-CC. Instead,
I should have commented that Aggregate Core Components should be
associated with their Core Components (or vice-versa) using the
Association mechanism of the registry.

> Although, "InheritsFrom" might be useful when connecting CC-BIE.
> We'll get there...
> 
> > [S5]
> > Stored Aggregate Core Components shall contain one or more Core
> > Component Properties (p.76 Section 7.1.3)
> >
> > [JMC] Covered by comment for [S4] above.
> 
> [Diego] Disagree. Same reason. As I see it, [S5] is saying that 1 ACC
> "Contains" references to 1..* CCs. And since Associations also have
> Slots, it can accommoddate i.e. cardinality and property term.
> 

[JMC2] I concur. We may also want to consider one-to-many associations
to represent ACC-> CC cardinality rather than using association Slots.

> > [S6]
> > Stored Aggregate Core Components can be referenced by one or more
> > Association Core Component Properties (p.77 Section 7.1.5) of other
> > Aggregate Core Components (p.76 Section 7.1.2)
> >
> > [JMC] (repeat of earlier comment) Association Core Component probably
> > not needed - will represent this functionality using the existing
> > registry Association mechanism.
> 
> [Diego] +1.
> I'd like to hear (from Mark?) the CCTS goal with ASCC, why not to say
> that Aggregates can contain aggregates? Is ASCC just a way to represent
> "ACCRef", or reference to an ACC? Or are we missing something?

[JMC2] I am compiling a list of questions for CCTS that we will present
to them at some point in the near future (when we have collected
enough). I will make this the first question on our list.
 
> > [S7]
> > Stored Aggregate Core Components shall include an "Object Class Term"
> > attribute
> >
> > [JMC] Note that this does not include the other 2 main Data Element
> > Terms from 11179 - Property Term and Representation Term. Is this
> > intended, or an error in the spec? According to the p.12 example,
> > "Person. Details" is an Aggregate Core Component, and it contains only
> > an Object Class Term of "Person" ("Details" would not be considered a
> > Representation Term). So [S7] is consistent with the p.12 example.
> >
> > [JMC] However, this leads to another question: What if one needed to
> > represent "Person" information in 2 different ACC's - for example, one
> > being "PersonEmploymentDetails", the other being
> > "PersonMedicalDetails".
> > According to [S7], this would not be possible. Or, are
> > "PersonEmploymentDetails" and "PersonMedicalDetails" not considered to
> > be ACC's?
> 
> [Diego] Is it a matter of how you see? From a different point of view,
> you can have 2 ACCs, "EmployeeDetails" and "PacientDetails", both
> containing "PersonDetails" ACC. Doesn't solve your problem but presents
> a work-around. Somebody should still answer Joe's question.

[JMC2] Good points. I will include this question on our CCTS question
list.
 
> 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