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

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

Forwarded on behalf of Diego. Please see comments marked with <JMC2>.

Diego Ballvé wrote:
> 
> Joe,
> 
> Please forward this mail to the list. Inline comments prefixed by "diego:".
> 
> Tks,
> Diego
> 
> > 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>
> 
diego1:
Agree till here, except for the absence of primitive type. I think
I missed the chance to comment this for [S26], but IMO it helps to
keep primitive type in the CCT, as a Slot. I understand it is defined
by CCTSpecs in a table, but I feel more confortable having it with
the stored CCT. You can directly see the basic type of info when
reading CCT's name/description/version/primitiveType/etc from the
registry, instead of having to use a table lookup. No big deal,
though.

<JMC2>
Great idea Diego - I completely agree. Let's add "Primitive Type" as an
attribute (using a Slot) of CCT.
</JMC2> 

> > [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>
> 
diego1:
Almost perfect! That's the way I see it and how I believe it should be,
except for "Expression Type". Just because we don't enough about
expression type (internally we've had doubts about which reg exp sintax
to use, for instance) i don't think we can simply chop it off.. there
must be a reason and a format for it and if we're not satisfied with
adding it as a Slot withouth knowing more about it we have to defer to
CCTS team.

<JMC2>
Good point - perhaps we can think about this some more. Does anyone have
ideas as to what purpose "Expression Type" may serve?
</JMC2>
 
> >
> > [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>
> 
diego1:
Reminder: Current Registry specs states that slots have maximum length.
Currency will fit there without problems but some other data might not.

<JMC2>
Great point - we've considered removing the "maximum length" aspect of
Slots. Are we still thinking of doing this?
</JMC2>

Also, one of the points David was raising a few months ago was the
handling of codelists. We should probably review those mails and
give "Restriction Value" some thought.

<JMC2>
A (manual) search on the archives did not yield anything in particular -
is there anything specific you're considering?
</JMC2>
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