Re: [Fwd: [regrep-cc-review] Association Core Components - Represent with Associations]

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

Please see comments below marked with <JMC>.

Chiusano Joseph wrote:
> 
> Forwarding on behalf of Diego, who makes some great points below.
> 
> I'm heading downtown now for a federal "E-Forms for E-Gov" meeting, and
> will be back online in about 4.5 hours. In the interim I would encourage
> anyone (observer or participant) to respond to Diego's points below - in
> any event, I'll weigh in later today.
> 
> Joe
> 
>   ------------------------------------------------------------------------
> 
> Subject: RE: [regrep-cc-review] Association Core Components - Represent with Associations
> Date: Wed, 16 Jul 2003 15:51:37 +0300
> From: Diego Ballvé <diego.ballve@republica.fi>
> To: "Chiusano Joseph" <chiusano_joseph@bah.com>
> 
> Joe,
> 
> This is getting interesting :)
> Pleas forward to cc-review
> 
> > <Quote1>
> > Ok.. just keep in mind that CCProperties are not stored independently.
> > Theiy are part of the referenced ASCC/BCC, meaning its attributes go
> > to wherever the ASCC/BCC attributes go. If ASCC is a RIM Association,
> > the Association will contain Slots with CCProperties attributes and
> > ASCC attributes.
> > </Quote1>
> >
> > That's an excellent point, Diego. Thinking back to the "Core Component
> > Properties" entity (CCTS p.76) - it has the following attributes:
> >
> > - Property Term
> > - Cardinality
> >
> > In terms of the Data Element Name, the only difference between an ACC
> > and an ASCC is that the ASCC provides an Object Class Qualifier Term -
> > e.g. "Residence" for the Object Class "Address". So I believe the
> > Property Term would remain with the ACC, and not be placed with (or
> > repeated on) the ASCC.
> 
> Are you sure about the qualifiers for CCs? I was not and this is what
> I've digged from the specs:
> 
> [B14] The definition of a Basic Business Information Entity shall use a structure that is
> based on the existence of the Object Class Term, the Property Term, and the
> Representation Term, and enhanced by business related Qualifier Terms.

<JMC>
I see a discrepancy with the above requirement and Figure 7-1 on p.75.
If we think in terms of the 11179 Data Element Terms and where they are
placed (per the "11179 Terms/CCTS Entities document I sent recently -
dated 7/7/03), we have:

Object Class 		- resides with the ACC
Property Term		- resides with the BCC/ASCC
Representation Term	- resides with the CTT

Since a BBIE is "derived" from a BCC, there would be no Object Class -
an Object Class would not enter into the picture until aggregation is
done. I recommend we consider this an inconsistency in Section 6 of the
CCTS spec and defer to Section 7 as our "official" requirement. Does
that sound good?
</JMC>

> [B15] The definition of an Association Business Information Entity shall use a structure
> that is based on the existence of the Object Class Term, the Property Term and
> the Object Class Term of the Aggregate Business Information Entity on which the
> corresponding Association Business Information Entity Property is based, and
> enhanced by business related Qualifier Terms.

<JMC>
Same response as my previous one.
</JMC>

> 
> If still we have qualifier for Object Class, then it's not shown on
> those UML diagrams we've been studying.

<JMC>
Figure 7-3 on p.85 shows a Qualifier Term as an attribute of ABIE -
which I believe is consistent with our discussions.
</JMC>
 
> > In terms of Cardinality, I believe this would be a different case.
> > Suppose we had an ACC called "Address. Details", and 2 ASCCs
> > (as in the
> > CCTS example we have been citing) that ultimate "resolve" to
> > "Residence
> > Address" and "Official Address" (just using English terms here for
> > simplicity). One may want to assemble a schema from Core
> > Components that
> > specifies a cardinality of (for example) "2" for Residence
> > Address, and
> > "3" for Official Address (that not make sense, but let's
> > pretend it does
> > for our purposes). If the Cardinality attribute were with the ACC, one
> > would not be able to make that distinction. So it appears
> > then that the
> > Cardinality attribute should reside with the ASCC, so that this
> > distinction can be made.
> >
> > How does that sound to you?
> 
> 100% agree on cardinality. That is exactly the point!!
> Now, extend it to Property Term:
> If you have a Person. Details with 2 properties of type address (ASCC
> to Address. Details) 

<JMC>
Address is not a Property Term - it is an Object Class.
</JMC>

then you identify them using different Property
> Terms (as you suggested, "Residence Address" and "Official Address").

<JMC>
"Residence" and "Official" would be Object Class Qualifiers that qualify
the Object Class "Address".
</JMC>

> If that would be stored in the ACC, then the Property Term would be
> the same for both properties, what would not be correct.

<JMC>
The Object Class "Address" is the same for both entities (ASCC and ACC),
which is correct.
</JMC>
 
> Same case for Business Term. You do need to redefine these
> attributes since they are not necessarily the same in te ASCC as
> for the ACC.

<JMC>
[S3] defines Business Term as "A synonym term under which the Core
Component is commonly known and used in a business.". Not sure of the
connection with ASCCs and ACCs, and where the significance is in your
explanation above. Please clarify.
</JMC>
 
> See attached example Schema which illustrate possible BIEs for the
> same example (BIEs, not CC!!!). It follows the UBL way.. I can soon
> send a possible SubmitObjectsRequest for it, if required. Then you
> can see the ExtrinsicObjects and Associations.

<JMC>
Thanks - I'll look it over (since it follows UBL, I will immediately
recognize what is being done). ;)
</JMC>

> > <Quote2>
> > I can then ask you why do we need BCC (which are similarly combined
> > with corresponding CCProperty) as ExtrinsicObjects, if they require
> > an Association to a DataType - and this RIM Association could contain
> > BCC + BCC Property attributes??? (I'm stretching it to the limit here)
> > </Quote2>
> >
> > Another excellent point. My response would be that a BCC is the basic
> > stored block of information with which other "blocks" are combined
> > (using term loosely) to form the entities that ultimately
> > reside in (for
> > our purposes) XML documents - BIEs and BBIEs. ASCCs are not
> > fundamental
> > building blocks - they build *upon* another fundamental
> > building block,
> > an ACC. So I view them as an extension of ACCs - they signify the role
> > that an ACC plays within an another ACC, and act as the "glue" that
> > joins 2 ACCs together.
> 
> Agree with restrictions. IMO ACC are the blocks you can use and abuse.
> Both BCC and ASCC are parts of these blocks, simple parts or composite
> parts. They only exist inside the ACC, though. As the ASCC is the glue
> that joins 2 ACCs together (through a property), the BCC is the glue
> that joins ACC and DataType (through a property). And Yes, BCC is a
> basic block, but you can still decompose it into ContentComponent and
> SupplementaryComponent, plus restrictions. For the XML representation,
> XML Elements and Attributes.

<JMC> 
Let's keep in mind that we are disregarding Properties as entities for
at least the time being. I personally don't view ACC as the "glue" that
joins ACC and Data Type, but Figure 7-1 can certainly be interpreted
that way (so I agree with your interpretation). I view ACCs simply as
aggregates of BCCs.

So: Where do you stand on the issue of using Associations to represent
ASCCs? :)
</JMC>

> Regards,
> Diego
> 
> 
> > Diego Ballvé wrote:
> > >
> > > Chiusano Joseph wrote:
> > > >
> > > > <Quote1>
> > > > We agreed on not to add Slots to RIM Association for clarity
> > > > and I think
> > > > it makes sense.
> > > > </Quote1>
> > > >
> > > > Ah - I'm reconsidering here, in this context. :) I
> > believe that this
> > > > approach was not good for Properties, but is good for ASCCs.
> > >
> > > Ok.. just keep in mind that CCProperties are not stored
> > independently.
> > > Theiy are part of the referenced ASCC/BCC, meaning its attributes go
> > > to wherever the ASCC/BCC attributes go. If ASCC is a RIM
> > Association,
> > > the Association will contain Slots with CCProperties attributes and
> > > ASCC attributes.
> > >
> > > I can then ask you why do we need BCC (which are similarly combined
> > > with corresponding CCProperty) as ExtrinsicObjects, if they require
> > > an Association to a DataType - and this RIM Association
> > could contain
> > > BCC + BCC Property attributes??? (I'm stretching it to the
> > limit here)
> > >
> > > Probably the reason is clarity. Desired? Needed? That I can't answer
> > > alone.
> > >
> > > Regards,
> > > Diego
> >
> 
>   ------------------------------------------------------------------------
>                            Name: Page12Example.xsd
>    Page12Example.xsd       Type: BizTalk Schema (text/xml)
>                        Encoding: base64
>                     Description: Page12Example.xsd
> 
>   ------------------------------------------------------------------------
> 
>   Joseph M. Chiusano <chiusano_joseph@bah.com>
>   Senior Consultant
>   Booz | Allen | Hamilton
>   IT Digital Strategies Team
> 
>   Joseph M. Chiusano
>   Senior Consultant           <chiusano_joseph@bah.com>
>   Booz | Allen | Hamilton
>   IT Digital Strategies Team
>   8283 Greensboro Drive       Work: (703) 902-6923
>   McLean
>   VA
>   22012
>   Additional Information:
>   Last Name    Chiusano
>   First Name   Joseph
>   Version      2.1
> 
>   ------------------------------------------------------------------------
> 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