CCTS Spec RIM Mappings - [S31] to [S34]

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

Team,

Here is the next set of CCTS requirements for us to cover - please see
my comments marked with <JMC>. Feedback is encouraged and appreciated.

Thanks,
Joe

[S31]
Stored Content Component Restrictions shall only be used to define
format restrictions on the Primitive Type of the Content Component of
the Core Component Type on which the Data Type is based. The list of
allowed format restrictions per Primitive Type is defined in Table 7-1.

<JMC>
I believe this requirement is more of an "FYI" as to what Content
Component Restrictions are about - so there would not be any impact on
the registry.

Having said that - here's an example:

Suppose we have a BCC that is associated with a Data Type whose
associated Core Component Type (CCT) is "Amount. Type". Also, this CCT
Type is associated with a Supplementary Component whose name is
"Currency Codes" (i.e. will provide a list of possible values for
Currency Codes).

According to Table 8-2 (p.97), the Primitive Type of the Content
Component (even though we are currently not planning on representing
Content Components in the registry) would be "decimal".

Swing back up to Table 7-1 (p.80), and we see that there are multiple
choices for format restrictions for primitive type "decimal":

- Total Digits: Defines the maximum number of digits to be used.
- Fractional Digits: Defines the maximum number of fractional digits
to                       be used.
- Minimum Inclusive: Defines the lower limit of the range of
allowed 		     values. 
- Maximum Inclusive: Defines the upper limit of the range of
allowed 		     		     values. 
etc.

This example will continue below in the notes for [S32].
</JMC>

[S32]
Stored Content Component Restrictions shall contain the following
attributes:

- Restriction Type: Defines the type of format restriction that applies
to the Content Component.

- Restriction Value: The actual value of the format restriction that
applies to the Content Component.

- Expression Type: Defines the type of the regular expression of the
Restriction Value.

<JMC>
Since we are currently not planning on representing Content Components
as entities in the registry, let's consider "Content Component" here to
mean "the value that is associated with a Basic Core Component in an XML
instantiation" (we know it does not have to be XML, but we can use this
for example purposes).

So the attributes described above can now be described as:

- Restriction Type: Defines the type of format restriction that applies
to the value that is associated with a Basic Core Component in an XML
instantiation.

- Restriction Value: The actual value of the format restriction that
applies to the value that is associated with a Basic Core Component in
an XML instantiation.

- Expression Type: Defines the type of the regular expression of the
Restriction Value.

So let's assume that:

- We are dealing with a decimal value (as described above for [S31])
- We are dealing with a format restriction of "Total Digits" 
- The total number of digits allowed is 5

The Content Component Restriction attributes would hold the following
values:

- Restriction Type: "Total Digits"
- Restriction Value: "5" 

That seems pretty straightfoward - these 2 attributes could be Slots on
the "Content Component Restriction" ExtrinsicObject.

Regarding "Expression Type": There is no other mention of this attribute
in the entire CCTS, except for Figure 7-1 (p.75). In light of that, I
recommend that we do not include it in our RIM mapping.
</JMC>

[S33]
Stored Supplementary Component Restrictions shall only be used to
restrict the possible values of the Supplementary Component of the Core
Component Type on which the Data Type is based.

<JMC>
As with [S31] I believe this requirement is more of an "FYI" as to what
Supplementary Component Restrictions are about - so there would not be
any impact on the registry.

Having said that - here's an example:

Suppose (as with [S31]) we have a BCC that is associated with a Data
Type whose associated Core Component Type (CCT) is "Amount. Type".
According to Table 8-1 (p.94), one of the Supplementary Components for
CCT "Amount. Type" is "Amount. Currency. Identifier".

In order to restrict the Supplementary Component values (i.e. to a
specific set of accepted Currency Codes), we would need to:

- Create a Supplementary Component Restriction
- Associate this Supplementary Component Restriction with the Data Type
(as per Figure 7-1, p.75)
- Provide the name of the Supplementary Component in the Supplementary
Component Restriction
- Provide the allowed list of values in the Supplementary Component
Restriction

So we can really "re-use" a Supplementary Component over and over, and
just place different restrictions on it as required for a given
situation.
</JMC>

[S34]
Stored Supplementary Component Restrictions shall contain the following
Attributes:

- Supplementary Component Name: Identifies the Supplementary Component
on which the restriction applies.

- Restriction Value: The actual value(s) that is (are) valid for the
Supplementary

<JMC>
So let's assume that we have the following attribute values (continuing
scenario described above in [S33]:

- Supplementary Component Restriction. Supplementary Component Name:
"Currency Codes"
- Supplementary Component Restriction. Restriction Value value: "USD"
- Supplementary Component Restriction. Restriction Value value: "EUR"
(etc. for all allowed values)

That seems pretty straightfoward - these 2 attributes could be Slots on
the "Supplementary Component Restriction" ExtrinsicObject.
</JMC>
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