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 (7.1.1-7.1.2)


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?

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.
 
 
> [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?


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]