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: CCTS Spec RIM Mappings (7.1.1-7.1.2)


Team,

I've added some comments as a first cut - please see [JMC] below.

Thanks,
Joe

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

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?

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

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

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