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] CCTS Spec RIM Mappings (7.1.3-7.1.7)


Thanks Monica and Diego - this is very helpful. A few comments below,
and then I've provided some more information on Data Types and Figure
7-1 (in general) that may help clear things up for us.

<Quote1>
For example, properties on Person could be Person ID, First Name, etc.
</Quote1>

[JMC] So another way to view this is a Person could be an ACC and these
properties would be BCC's. This is consistent with CCTS spec p.11 "A
Basic Core Component represents a Basic Core Component Property and is
therefore of a Data Type,...".

<Quote2>
p.76:

  7.1.3 Stored Core Component Properties

  [S8]
  Stored Core Component Properties shall be stored as part of the stored
  Aggregate Core Component to which they belong, i.e. they shall never
  exist independently of their owning Aggregate Core Component.
    

mm1: If you look at the reference above, this can be taken a bit further
- a BCC is part of an ACC.  
 
<Diego>
Then Joe and I got it wrong. We thought you would be able to define BCCs
and add them to registry as independent parts then compose an ACC
If that is not possible, an ACC with its (B)CCs is the smallest part you
can store in the registry at once.
Actually it makes sense, if you consider that the specs say that you can
only reuse ACC through ASCC.. no mentioning on reusing BCC.
</Diego>
</Quote2>

[JMC] I'm not so sure we got it wrong - in fact, I'm not sure if the
spec clearly states that one cannot register BCCs separate from ACCs. In
Figure 7-1 (p.75) it clearly shows ACCs and BCCs as separate stored
entities. Diego, can you please research this more in the CCTS spec if
you have a chance?

Below I list some CCTS references regarding Data Type and Properties, a
"rough example" that walks through Figure 7-1 on p.75. Hopefully this
can help clear up the roles of Data Types and Properties, and whether or
not we even need to represent them in the registry. Please let me know
what you think.

REFERENCES:

p.11: 

A Basic Core Component represents a Basic Core Component Property and is
therefore of a Data Type, which defines its set of values. Basic Core
Components function as the Properties of Aggregate Core Components.

p.12: 

Most of these Properties are Basic Core Components. These Properties
represent a singular business characteristic and their set of allowed
values is defined by a Data Type. The Data Types* Name, Street, Post
Code and Town are of the Data Type Text, Birth Date is of the Data Type
Date and Country is of the Data Type Identifier.

*This is a misprint, and should read "Properties" instead of "Data
Types".

p.79:

[S29] Stored Data Types shall have a Core Component Type as their basis.

[S30] Stored Data Types may include one or more Content Component
Restrictions and one or more Supplementary Component Restrictions to
provide additional information on the relationship between the Data Type
and its corresponding Core Component Type. They identify restrictions on
the format of the Content Component and/or restrictions on the possible
values of the Supplementary Components of the corresponding Core
Component Type.

p.105:

Data Type - Defines the set of valid values that can be used for a
particular Basic Core Component Property or Basic Business Information
Entity Property. It is defined by specifying restrictions on the Core
Component Type that forms the basis of the Data Type.

ROUGH EXAMPLE:

- Suppose there is an Aggregate Core Component (ACC) called
"OrderDetails"

	à Figure 7-1: AggregateCoreComponent.ObjectClassTerm is "Order" 

- One Basic Core Component (BCC) that is contained within this ACC is
"Total" (full data element name would be "OrderTotalAmount")

	à Figure 7-1: See middle right, "Basic Core Component (BCC)"
Also: CCProperty.PropertyTerm is "Total"

- According to CCTS spec, "Total" not only represents a BCC - it also
represents a BCC Property (Basic Core Component Property)

	à Figure 7-1: See middle left, "Basic CC Property"

- The "Data Type" entity allows us to add a Qualifier Term - but let's
assume that we don't need one here (i.e. "OrderTotalAmount" is
semantically sufficient to describe what the data element represents)

- However, we do need to specify the Core Component Type (CCT)
information. The "Data Type" entity connects a BCC to a CCT, through the
"Basic CC Property" (i.e. BBC à Basic CC Property à Data Type à CCT).
Note that we did not include any attribute information for the Data
Type, because we did not need to specify a Qualifier Term (i.e. we would
have a RegistryObject with no attributes other than the RIM-required
ones).

- With the CCT, we specify a Primary Representation Term of "Amount"
(i.e. OrderTotalAmount), and no Secondary Representation Term. We define
ContentComponent.PrimitiveType to be "decimal" (which stipulates that
our OrderTotalAmount value must be decimal). 

- Since our CCT is "Amount. Type" (see p.94 Table 8-1), we can have 2
Supplementary Components (right column of Table 8-1):
AmountCurrency.Identifier and AmountCurrency.CodeListVersion.Identifier.
We will use only AmountCurrency.Identifier here for brevity.

- Our SupplementaryComponent.PrimitiveType will be "string", and we will
provide a list of "PossibleValues" (USD, EUR, etc.)

- We wish to restrict both the Amount value and Currency Identifier
values. For this BCC (through the intermediaries of Basic CC Property
and Data Type), we assign ContentComponentRestriction.RestrictionType to
be "Maximum Inclusive" (see p.80 Table 7-1) and
ContentComponentRestriction.RestrictionValue to be (for example)
$100,000.00.

- We also assign SupplementaryComponentRestriction.RestrictionValue to
be a list of accepted Currency types, such as "USD" and "EUR".

CONCLUSION:

It appears to me that Data Type is not performing much of a function
except to "hold" a Qualifier Term. Otherwise, it is just connecting
entities that don't need to be connected by an intermediary.

Same with Basic CC Property - except that Basic CC Property seems to be
performing a strictly intermediary role (no attributes).

I now see the CC Property as having value - in that it specifies the
cardinality for a BCC within an ACC. This allows us to define a BCC once
and use it in multiple ACC's with a different cardinality value each
time. However, I'm not sure why the Property Term cannot be assigned to
the BCC itself rather than the CC Property.

Joe
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


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