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] Association Core Components - Represent withAssociations


<Quote1>
An instance of type ASCC can be seen as a CC since extends CC (it has
all CC fields).
</Quote1>
AND
<Quote2>
Sorry, but I still cant see the replication.
</Quote2>

Since ASCC extends CC (it has all the CC fields plus more): If an ASCC
were represented as a RegistryObject (rather than an Association with
Slots), wouldn't values for the fields that it has in common with CC be
duplicated as well? If not, what values would the ASCC fields hold?

[Keeping in mind that the fundamental question is still: Should an ASCC
be represented as an Association that "connects" two ACCs in the
registry, with additional Slots to represent things such as Cardinality
and Object Class Qualifier]

Joe

Diego Ballvé wrote:
> 
> > <Quote1>
> > ps. I'm out-of-oasis till my CEO renew our membership. I guess I
> > still get mails but I can't mail the list.
> > </Quote1>
> >
> > Sorry to hear that Diego - I hope you'll contain to provide
> > feedback to
> > Farrukh and I, and I will copy the CC Review listserv on my replies to
> > you. Hope your membership is renewed soon - otherwise you could always
> > join as an individual member. :)
> 
> Sure. You won't get rid of me so fast. ;)
> 
> > <Quote3>
> > > the Object
> > > Qualifier. This could be viewed as an inefficient use of storage and
> > > difficult to maintain (would need to keep an ACC and ASCC in sync in
> > > terms of their attribute values).
> > Which attributes?? ASCC has businessTerm, which can differ from its
> > corresponding ACC's businessTerm (i.e Address, Residence Address,
> > Official Address).
> > </Quote3>
> >
> > ASCC has Business Term because it is "a particular category of Core
> > Components" [S17], which include a Business Term [S3]. [S17]
> > also states
> > "stored Association Core Components shall include all Attributes of
> > stored Core Components.". That is the basis for my observation that we
> > would need to replicate attribute values between ACCs and ASCCs. Hope
> > that makes it clearer.
> 
> Yes, that is the "type" definition. Don't mix with "instance" definition
> already talking OO. The type for ASCC extends the type for CC, inheriting
> CC type's attributes (not the type for ACC, btw). An instance of type
> ASCC can be seen as a CC since extends CC (it has all CC fields). It does
> not extend an ASCC and it does not (necessarily) have the same fields.
> Even if it does (say the types were difined the same way), each one is a
> different instance thus fields can have different values. Sorry, but I
> still cant see the replication.
> 
> >
> > <Quote3>
> > Name?? Well, that you also have problems with BBIE, if you decide to
> > change parent ABIE's objectClass.
> > </Quote3>
> >
> > I assume you mean Dictionary Entry Name. I want to make sure I address
> > your concern above: Suppose we have a BBIE called "US_Address. Street.
> > Text". It is contained within an ABIE called "US_Address. Details"
> > (Object Class is "US_Address"). If one decides to change the parent
> > ABIE's Object Class to "UK_Address", in my mind that change should
> > propagate to all BBIEs contained within the ABIE (we're into
> > implementation here, and beyond the specification). That should be the
> > function of a Registry user-facing tool that interacts with the Core
> > Components stored and maintained in the Registry. There should also be
> > another "trigger" that says that any time a part of a 11179
> > Data Element
> > Name (the 5 parts of Object Class Qualifier, Object Class,
> > etc). changes
> > for any entity within the Registry (ex: Property Term changes on an
> > ACC), that change should automatically propagate back to the
> > Dictionary
> > Entry Names for all entities whose Dictionary Entry Names
> > depend on that
> > changed Data Element Name part.
> 
> Exactly. On this matter we're synchronized then.
> 
> > So in summary, I don't think that anyone will "have problems", as long
> > as their implementation handles these scenarios properly. I am in the
> > process of putting together a document that details the
> > actions that can
> > be taken by users in regards to Core Components (e.g. create
> > a BIE from
> > an BCC, include an ACC within another ACC using an ASCC) and the order
> > in which they can happen, to see if there are any snags that we should
> > be aware of. Please stay tuned for this - it will take a few weeks.
> >
> > Joe
> >
> > Diego Ballvé wrote:
> > >
> > > Chiusano Joseph wrote:
> > >
> > > > <Quote2>
> > > > So I am leaning towards Association with Slots approach.
> > > > </Quote2>
> > > >
> > > > I am as well, but I'm keeping an open mind. Others? What are the
> > > > arguments in favor of not taking this approach? It seems
> > to me that if
> > > > we represent ASCC as an ExtrinsicObject, we need to replicate the
> > > > attribute values from the BCC it is "derived" from, plus add
> > >
> > > should be **from the ACC it is "derived" from**, not BCC.
> > >
> > > > the Object
> > > > Qualifier. This could be viewed as an inefficient use of
> > storage and
> > > > difficult to maintain (would need to keep an ACC and ASCC
> > in sync in
> > > > terms of their attribute values).
> > >
> > > Which attributes?? ASCC has businessTerm, which can differ from its
> > > corresponding ACC's businessTerm (i.e Address, Residence Address,
> > > Official Address). Name?? Well, that you also have problems
> > with BBIE,
> > > if you decide to change parent ABIE's objectClass.
> > >
> > > From another mail:
> > > 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)
> > >
> > > Coming from an Association with Slots approach but not sure if that
> > > was the best and clearest approach to choose, regards,
> > >
> > > Diego
> > >
> > > ps. I'm out-of-oasis till my CEO renew our membership. I guess I
> > > still get mails but I can't mail the list.
> >
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]