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] CCT Submission: Example


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




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