[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)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]