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: [REVISITED] Re: [regrep-cc-review] CCTS Spec RIM Mappings (7.1.1-7.1.2)


Team,

Now that we've cleared up some of our understanding of ASCCs/ASBIEs,
Properties, and DataTypes, I'd like to revisit some of the open
requirements. For this set, we'll start with [S4] - the preceding ones
were already addressed. Please see my comments below marked with <JMC>.

[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>
Our most recent discussions have been: A Core Component is either a
Basic Core Component (BCC) or Aggregate Core Component (ACC). Therefore,
not only are Aggregate Core Components a particular category of Core
Components, but Basic Core Components are as well. 

There is no special registry treatment for this requirement - it is
explanatory.
</JMC>

[S5]
Stored Aggregate Core Components shall contain one or more Core
Component Properties (p.76 Section 7.1.3)

<JMC>
There is no special registry treatment for this requirement - it is
explanatory.
</JMC>

[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>
There is no special registry treatment for this requirement - it is
explanatory. However, per our most recent ASCC discussions, we can
provide the "reference" described above using Associations.
</JMC>

[S7]
Stored Aggregate Core Components shall include an "Object Class Term"
Attribute

<JMC>
We can use a Slot on the ACC RegistryObject for this. 

A side note: The CCTS spec has "divided" the ISO/IEC 11179 Data Element
Terms (Object Class, Property Term, etc.) into:

Object Class: An attribute of Aggregate Core Component (ACC) - see [S7]

Object Class Qualifier Term: An attribute of Aggregate Business
Information Entities (ABIE) - see [S52] 

Property Term: An attribute of Basic Core Component (BCC) - see [S10]

Property Term Qualifier Term: An attribute of Data Type - see [S28]

Representation Term: An attribute of Core Component Type (CTT) - see
[S22]

So, given the following Data Element Name (|'s used to separate Data
Element Terms):

Temporary | Employee | Home | Telephone | Number
    OCQT          OC         PTQT        PT	   RT

Regarding Property Term Qualifier Term (PTQT): I question the placement
of the Qualifier attribute on Data Type. It seems that it belongs on
BIEs instead. Here's why:

- Object Class is an attribute of ACC;

- Object Class Qualifier Term is an attribute of ABIE; the Qualifier
Term gives business context to the ACC, making it an ABIE (through
classification according to one of the 8 context categories).

So it seems natural that since Property Term is an attribute of BCC, the
Property Term Qualifier Term should be an attribute of [BCC + business
context], which is BIE. 

Does anyone think that this is an error in the CCTS spec?
</JMC>

Joe

Chiusano Joseph wrote:
> 
> Team,
> 
> I'm in the process of revising our Workplan given the clarification of
> our scope last week. I'm also creating items such as an issues list,
> requirements, etc. - please stay tuned for these.
> 
> In order to keep our great discussions flowing, I'd like to jump into
> the CCTS spec today and start a thread on a few parts of CCTS Section 7,
> specifically:
> 
> pp.74-76 Section 7.1, Subsections 7.1.1 - 7.1.2 (inclusive)
> 
> Below I've reproduced most of the text from these sections - please
> comment on how each requirement can be represented in our current RIM if
> applicable (or if the Slot mechanism should be used). Some requirements
> have already be covered last week (ex: Dictionary Entry Name), and are
> marked as such. Please feel free to simply insert a comment underneath
> each item that you'd like to comment on. I've also provided page and
> section #'s for reference where necessary.
> 
> Thanks in advance for your feedback.
> 
> Joe
> 
> p.75:
> 
> 7.1.1 Stored Core Components
> 
> [S1]
> - Unique Identifier
> - Version
> - Dictionary Entry Name (already covered: RegistryObject.name)
> - Definition (already covered: RegistryObject.description)
> - Usage Rule: See p.65 Section 6.2.4
> 
> 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)
> 
> [S3]
> - Business Term
> 
> 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.
> 
> [S5]
> Stored Aggregate Core Components shall contain one or more Core
> Component Properties (p.76 Section 7.1.3)
> 
> [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)
> 
> [S7]
> Stored Aggregate Core Components shall include an "Object Class Term"
> attribute
> 
>   ------------------------------------------------------------------------
> 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]