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

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

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

---

• From: Diego Ballvé <diego.ballve@republica.fi>
• To: "Chiusano Joseph" <chiusano_joseph@bah.com>
• Date: Wed, 16 Jul 2003 15:51:37 +0300

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.
[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.

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




> 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) then you identify them using different Property
Terms (as you suggested, "Residence Address" and "Official Address").
If that would be stored in the ACC, then the Property Term would be
the same for both properties, what would not be correct.

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.

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.



 
> <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.

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
> 

Page12Example.xsd

---

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