Re: [regrep-cc-review] BCC as RIM Association

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

Please see comments marked with <JMC>. This is coming together nicely!
Thanks Diego for this excellent analysis. I would encourage all Team
members to really dig into the details of this e-mail which references
CCTS Figure 7-1 in depth - this one's big. 

Since Diego's original UML diagram attachment didn't carry though on the
forward, I will send it later today.

Joe

Chiusano Joseph wrote:
> 
> Forwarded on behalf of Diego.
> 
> Diego Ballvé wrote:
> >
> > Joe,
> >
> > I'm trying to build some basis for my last proposal, BCC as
> > RIM Associattion. Please check this text while looking at CCTS
> > 1.9, page 75, Figure 7-1. Alsoattached a possible UML diagram
> > for this way to see CCTS.
> >
> > Regards,
> > Diego
> >
> > ----------------------------
> >
> > From botton right, with XML analogy, CCT - Core Component Type:
> > Gives the primitive type (decimal, int, string, data, binary)
> > for the information (ContentComponent, XML Element's text),
> > plus primitive type for extra info (Supplementary Component,
> > XML Element's attributes).
> >
> > Currently we've settled for having CCT, ContentComponent and
> > SupplementaryComponent as different ExtrinsicObjects, 

<JMC>
I'm glad you bring that up Diego - it's a great time to address this
issue. Make take is: the CCTS treats Content Components and
Supplementary Components as stored objects - but I believe that:

(a) We can potentially not represent Content Components at all, and
leave the "Primitive Type" attribute of Content Component as information
for the implementers (e.g. CCTS says "an Amount. Content" Content
Component holds a value whose value must be a decimal" - why have a
metadata attribute for "Primitive Type"?) 

(b) We probably do need to represent Supplementary Components - and
furthermore, we probably need to represent them as ExtrinsicObjects
(rather than Slots on a CCT), because of the metadata attributes that it
carries (Figure 7-1 bottom right).
</JMC>

though
> > there is a doubt wether CCT and ContentComponent could be
> > stored in the same RegistryObject.

<JMC>
Yes (see my comment just above).
</JMC>

> >
> > Next, DataType further restricts the CCT. Restrictions for both
> > Content and Supplementary Content. 

<JMC>
Yes.
</JMC>

Restriction types are limited
> > to a few types (Check page 80, table 7.1, of CCTS 1.9).

<JMC>
Yes.
</JMC>

> > Current mapping overview, 3 different RegistryObjects for
> > DataType, ContentComponentRestrictions and
> > SupplementaryComponentRestriction, connected by RIM Associations.

<JMC>
Yes - I'm looking at Figure 7-1, bottom. Great so far.
</JMC>

> >
> > In the middle of the picture, we've eliminated those 1 to 1
> > relations and merged the objects, keeping the name as xCC.
> > So (we need an UML for this):
> > - BasicCoreComponent (BCC) also contains Basic CCProperty fields;

<JMC>
Exactly - BCC needs to have a "Property Term" attribute and a
"Cardinality" attribute (the Cardinality attribute specifying its
mandatory/optional and repetition characteristics within an ACC).
</JMC>

> >   AggregateCoreComponent references ASCC directly (not via prop)

<JMC>
Absolutely - ACC does not reference ASCC directly in Figure 7-1 (it does
so through ASCC). Since we are currently omitting the notion of Property
as an entity, ACC would reference ASCC directly not via a Property.
Excellent.
<JMC>
> > - AssociationCoreComponent (ASCC) also contains Association

<JMC>
Yes - I am now more convinced (based on the excellent information you
gave recently) that we really may need to represent ASCC as an
ExtrinsicObject rather than simply an Association with Slots. And the
ASCC would itself be involved in 2 associations (to "join" the ACCs that
it associates, as per p.12 example).
</JMC>

> >   CCProperty fields; AggregateCoreComponent references ASCC
> >   directly (not via prop).

<JMC>
Absolutely.
</JMC>

> >
> > With this last change I'm not saying that we should modify CCTS
> > 1.9. We just see it in a different way when storing it.

<JMC>
Yes - we would not ask that anything in CCTS be modified. Rather, as
part of our ultimate feedback to the UN/CEFACT CCTS Team we will
describe to them anything that we treated differently in the registry
architecture than is specified in the CCTS. Updating the CCTS would be
entirely up to them, if they choose to.
</JMC>

> > Attached is a modified UML diagram (sample! done with paint).
> > See the similarities between ASCC and BCC.
> >
> >   ------------------------------------------------------------------------
> >                                          Name: figure7-1-newInterpretation.jpg
> >    figure7-1-newInterpretation.jpg       Type: JPEG Image (image/jpeg)
> >                                      Encoding: base64
> >                                   Description: figure7-1-newInterpretation.jpg
> 
>   ------------------------------------------------------------------------
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
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