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

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

All,

I've taken the submission example from the original e-mail below one
step further, for the submission of a Data Type based on the
"Country_Code" CCT. I know that we're not defining an XML serialization
for Core Components (others are doing that), but I've been thinking
about how (in general terms) the registry representations would best
support an XML serialization.

To illustrate, here is an example from Gunther Stuhec's paper on
representing CCTs in XML format - "SecurityErrorCode" is a BCC based on
a "Code" CCT:

<SecurityErrorCode listID ="SEC" listAgencyID="4711"
listAgencySchemeID="PartyA"
listAgencySchemeAgencyID="ZZZ">ER05</SecurityErrorCode>

The above attributes correspond directly to the Slots that we are
providing for CCTs (which correspond to the metadata attributes from the
CCTS).  

So if an Assembly program were to serialize a BCC based on a "Code" CCT
into XML format (perhaps the value is extracted from a database), it
would take the Slot values from the CCT and assign them to attributes as
shown above, and provide the code value as the actual value.

Additionally, the "Possible Values" Slot on the CCT could be used to
validate the code value against the list of valid code values.

Now onto the Data Type example - please note the following:

- The Data Type is called "European_Country_Code", and it is based on
the CCT "Country_Code";

- This Data Type restricts the "Country_Code" CCT by including a subset
of the "Country_Code" values;

- Per the CCTS, we include a Slot for "Representation Term Qualifier
Term" to "differentiate the Data Type from its underlying Core Component
Type"

- We associate the Data Type to the CCT using a "Restricts" association
(this is a new Association Type that I'm proposing we use for
registration of Data Types);

- As with the CCT submission example (Supplementary Component), I placed
the attributes from Supplementary Component Restriction and Content
Component Restriction on the Data Type as Slots instead of creating
additional ExtrinsicObjects (more lightweight). If anyone sees anything
incorrect with this approach, please let me know.

I've attached a Word document containing a slightly updated version of
the CCT submission example, and the new Data Type example. Comments are
welcome and appreciated.

Thanks!
Joe

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

Data Type and CCT Submission.doc

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