Re: [regrep-cc-review] CCT Submission: Example

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

Thanks Monica. How would you propose that we revisit this with the CCTS
team? Do we have a formal liaison? How does the current "atmosphere"
between OASIS and CCTS affect our communications with the CCTS team? Are
they required to update their specification if we point out an
inconsistency? 

Anyway, I think that what this boils down to is the following question:

- Is "Country_Code" a CCT or a Data Type?

According to Gunther's CCT document (XML representations), I believe
that Country_Code would be considered a CCT. The issue underlying the
question is that the CCTS lists multiple Supplementary Component
attributes (code list ID, agency, etc.) which - I believe - would need
to be tied to a specific code list (such as "Country_Code") rather than
a generic CCT called "Code. Type". So I can't see how we could register
a generic CCT called "Code. Type" - i.e. what values would the
attributes (code list ID, agency, etc.) have? That is why I interpret
"Country_Code" as being a CCT.

Thanks,
Joe

"Monica J. Martin" wrote:
> 
> Chiusano Joseph wrote:
> 
> >All,
> >
> >I started working on an example submission to the registry of a CCT
> >called "Code. Type", and I immediately became puzzled as to why we would
> >register an ExtrinsicObject representing a CCT such as "Code. Type",
> >with no values submitted (i.e. what values could we submit for such a
> >generic code list name)? So then I thought we could allow users to
> >submit more "specific" CCTs based on the "primitive" CCT's (Amount.
> >Type, Code. Type, etc.) - for example, "Country_Code. Type" (although
> >this looks like a Data Type, let's consider it a CCT for purposes of
> >this example).
> >
> >
> mm1: Although I have just briefly read this, Joe, I am not certain this
> compression is appropriate, i.e. Code. Type != Country_Code. Type. I
> think this discussion may need a revisit with CCTS team (which meets
> later this week). I understand your rational but still wonder about
> "specific" and "primitive" CCT.
> 
> >Below I've listed a submission of a CCT "Code.Type" for Country Codes,
> >which is quite different (and necessarily so, I believe) than what the
> >CCTS calls for. Either that, or I am misinterpreting the CCTS's
> >intentions.
> >
> >Please note, regarding the "SubmitObjectsRequest" example below:
> >
> >- I added a Slot for the CCT called "Possible Values"; for the
> >Country_Code. Type CCT, it will hold all possible Country Code values
> >based on which list is being used (indicated in the later Slots)
> >
> >- I took all of the Supplementary Component attributes (see p.97,
> >starting on left with "Code List. Agency. Identifier") and - instead of
> >creating an ExtrinsicObject for the Supplementary Component with these
> >attributes as Slots - I simply made them Slots on the CCT "Country_Code.
> >Type" itself. This seemed to be more sensible representation-wise.
> >
> >
> >- So if we need to submit a more "specific" type of country code (ex:
> >European countries only), a new CCT could be submitted with an
> >additional Representation Term to represent the specific concentration,
> >and the registry would need to ensure that the "Possible Values" are
> >either identical to, or a subset of, the "Possible Values" for the
> >"Country_Code. Type" CCT. Also, an association would be registered
> >between the new CCT and "Country_Code. Type" CCT.
> >
> >
> >
> >Here is the example:
> >
> ><SubmitObjectsRequest>
> >   <LeafRegistryObjectList>
> >
> >      <!-Register CCT-->
> >
> >      <ExtrinsicObject id="CCT_UUID" userVersion="1.0">
> >         <Name>
> >            <LocalizedString value="Code. Type">
> >         </Name>
> >         <Description>
> >            <LocalizedString value="Core Component Type Country Code.
> >Type">
> >         </Description >
> >         <Slot name="Business Term">
> >            <ValueList>
> >               <Value>This is the Business Term</Value>
> >            </ValueList>
> >         </Slot>
> >         <Slot name="Primary Representation Term">
> >            <ValueList>
> >               <Value>Code</Value>
> >            </ValueList>
> >         </Slot>
> >         <Slot name="Secondary Representation Term">
> >            <ValueList>
> >               <Value>Country</Value>
> >            </ValueList>
> >         </Slot>
> >         <Slot name="Possible Values">
> >            <ValueList>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >               <Value>Possible value</Value>
> >            </ValueList>
> >         </Slot>
> >         <Slot name="Code List. Agency. Identifier" datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> >   <Slot name="Code List. Agency Name. Text" datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> >   <Slot name="Code List. Name. Text" datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> >   <Slot name="Code List. Identifier" datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> >   <Slot name="Code List Scheme. Uniform Resource. Identifier"
> >   datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> ><Slot name=" Code List. Uniform Resource. Identifier"
> >      datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> >   <Slot name="Code List. Version. Identifier" datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> >   <Slot name="Code. Name. Text" datatype="string">
> >            <ValueList>
> >               <Value>Value goes here</Value>
> >            </ValueList>
> >         </Slot>
> >      </ExtrinsicObject>
> >   </LeafRegistryObjectList>
> ></SubmitObjectsRequest>
> >
> >Please provide feedback on the sensibility of this approach, compared
> >with what is outlined in the CCTS spec.
> >
> >Thanks,
> >Joe
> >
> >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.
> >
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to 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