Re: Feedback Due 9/5: Updated Requirements Mapping

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

Forwarded on behalf of Diego. Please see comments marked with <JMC16>.

Diego Ballvé wrote:
> 
> This was unanswered..
> > <JMC15>
> > > For instance ASCC.propertyTerm field and ASBIE.propertyTermQualifier,
> > > which can be used to generate XML element names according to HK's
> > > approach (see http://www.itsd.gov.hk/itsd/english/infra/eif.htm).
> >
> > Please cite a specific page/line in the URL above.
> > <JMC15>
> 
> This is more specific (the link was posted on this list before)
> http://www.itsd.gov.hk/itsd/english/infra/download/xml_schema_design_guide_v0_5_1.pdf
> See section 5.5.2, page 49.

<JMC16>
I believe the cited section is not consistent with the CCTS spec. It
asserts that the Property Term of a BBIE and the Property Term of an
ASBIE can have the same value ("shall be translated fom the Property
Term of the BBIE/ASBIE"), and this is not so according to the CCTS spec. 
I hope you don't mind if we skip this reference, else risk getting off
track.

Citing the CCTS p.16 example, there are 2 ASBIEs:

US_ Person. US_ Residence. US_ Address (Property Term = "US_Residence")
US_ Person. US_ Official. US_ Address (Property Term = "US_Official")

There is no BBIE listed in this example with a Property Term of
"US_Residence" or "US_Official".

Keeping in mind that ASCCs/ASBIEs are represented in our architecture as
Associations, my most current proposal was that the ASCC/ASBIE name be
created by the Assembly process that creates the XML serialization by
simply extracting the data element terms from their respective entities
and concatenating them. That is, for the CCTS p.16 example:

US_Person = Object Class Qualifier/Object Class of "outer" ABIE

US_Residence/US_Official = Object Class Qualifiers of "derived" ABIEs
(for example, "US_Residence" represents 2 Object Class Qualifiers: "US"
and "Residence")

US_Address = Object Class of "derived" ABIE 
(example of full name: US_Residence. US_Address. Details")

What do you think of this proposed handling? The other option is to
maintain the name of the ASCC/ASBIE in the Association as Slots, but I
believe this can add unnecessary maintainence overhead.
</JMC16> 

> > <JMC15>
> > > BTW, I'm saying we should worry about sintax binding.. just that we
> > > cannot cut things that CCTS defines and sintax binding
> > > implementers use. We (regrep+cc) are the bridge between this 2.
> >
> > As I've stated *multiple* times, the OASIS/ebXML Registry TC was not
> > brough into the process of creating the CCTS spec. Therefore, we have
> > the right - and we *will* usurp it - to interpret the CCTS spec in any
> > way in which we choose. I have raised up to Patrick Gannon
> > and Karl Best
> > (through Kathryn) the legal issues of our not being 100%
> > compliant with
> > the CCTS spec. That is the field that we're playing on, and
> > that is the
> > field we will continue to play on. Feel free to jump off if you don't
> > like the grass.
> > </JMC15>
> 
> Actually I'm jumping in again. We finally filled the renewal
> web-form yesterday and we're now waiting for international
> payment instructions, I guess - there should be a couple of
> ABIEs and a BPSS for membership renewal! ;)

<JMC16> 
Excellent!
</JMC16> 
 
> Back to the ASBIE, I understand that sometimes you don't need
> (and don't want!) extra layers on order to reuse BIEs - we're
> facing the same issue in Republica and our cludge is to have
> "EquivalentTo" Associations between ABIEs. Some other times
> what we need is the ASCC/ASBIE mechanism, with PropertyTerm
> and no new ABIE entity, just reuse. But I'm done with that.

<JMC16> 
To keep us advancing forward (which is my obligation to this initiative
and the participants), I'll remain the Team that we've decided to
represent ASCCs and ASBIEs as Associations in the registry, not as
entities. There should be no references to ASCCs/ASBIEs as entities in
the future, unless new infomation is discovered that may change our
approach (please :)).  
</JMC16> 
 
> Regards,
> Diego
> 
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Tuesday, September 02, 2003 10:23 PM
> > To: Diego Ballvé; CCRev
> > Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
> >
> >
> > Forwarded on behalf of Diego. Please see comments marked with <JMC15>
> > (getting bored with predictable sequences).
> >
> > Diego Ballvé wrote:
> > >
> > > Chiusano Joseph wrote:
> > > >
> > > > <JMC3>
> > > > The case you cite does not involve layers - it is
> > horizontal in nature
> > > > (extension), rather than vertical in nature (layers).
> > > > </JMC3>
> > >
> > > True. I used the wrong word. Not "creating new layers" but
> > > "creating new entities", that is something we also don't
> > > want to do, unless required (your next comment gives a
> > > possible reason: reuse).
> > >
> > > > <JMC3>
> > > > That is a perfectly acceptable (and common) occurrence. A
> > Person may
> > > > have multiple addresses associated with them. Additionally,
> > > > creating/storing/maintaining an entity called "ResidenceAddress.
> > > > Details" allows it to be reused in multiple scenarios. I'm
> > > > not sure what
> > > > the issue is here.
> > > > </JMC3>
> > >
> > > Is it really required to maintain a "ResidenceAddress. Details"
> > > if it only reuses what has been defined for "Address. Details"?
> >
> > <JMC15>
> > Absolutely not. A user should only do so if the "derived" ACC
> > ("ResidenceAddress. Details") is different than the "base" ACC
> > ("Address. Details") - for example, if "ResidenceAddress. Details" has
> > an additional element. But we probably cannot enforce this in the
> > Registry architecture - that is, we cannot stop users from derving an
> > ACC from another ACC and simply providing a different name without
> > modifying it. This would be up to implementations to enforce. If you
> > think we should add a requirement in our Technical Note that
> > states that
> > a derived ACC *must* be different than a base ACC, then it would be
> > worth considering.
> > </JMC15>
> >
> > > I can see CCTS Association doing this trick.
> >
> > <JMC15>
> > Yes - the base and derived ACCs will be linked via an
> > Association whose
> > assocationType is "derivedFrom".
> > </JMC15>
> >
> > What you cannot
> > > reuse is the "thing" that the Object Class (Aggregate) uses to
> > > identify each of its contents: PropertyTerm+PropertyTermQualifier.
> >
> > <JMC15>
> > Property Term is an attribute (Slot) of Basic Core Components. For
> > example, "Address. Street. Text" is a BCC (per CCTS p.12
> > example) whose
> > Property Term is "Street".
> > </JMC15>
> >
> > > I mean, you reuse "Address. Details" and identify it once as
> > > ResidenceAddress and once as OfficialAddress. ... I guess I'm
> > > getting repetitive..
> > >
> > > > <JMC3>
> > > > Not sure what fields you mean - I was referring to the
> > properties on
> > > > ASCCs/ASBIEs. Since we are not representing these as entities
> > > > (in the CC
> > > > sense) but rather as Associations, these properties are not
> > > > required for
> > > > ASCCs/ASBIEs.
> > > > </JMC3>
> > >
> > > For instance ASCC.propertyTerm field and
> > ASBIE.propertyTermQualifier,
> > > which can be used to generate XML element names according to HK's
> > > approach (see http://www.itsd.gov.hk/itsd/english/infra/eif.htm).
> >
> > <JMC15>
> > Please cite a specific page/line in the URL above. Citing the
> > CCTS p.12
> > example, there are the following ACCs:
> >
> > Person. Details
> > Address. Details
> >
> > In our work here, we would also create the following 2 ACCs
> > (this is not
> > in the CCTS spec):
> >
> > OfficialAddress. Details
> > ResidenceAddress. Details
> >
> > We would then join each of these 2 ACCs to the "Person. Details" ACC
> > with an Association. If one wanted to instantiate these Association in
> > an XML document, they would call them:
> >
> > Person. Official. Address
> > Person. Residence. Address
> >
> > Dissecting the first name above ("Person. Official. Address") it would
> > be constructed as follows:
> >
> > Person = Object Class of "Outer" ACC (Person. Details)
> > Official = Object Class Qualifier of "Inner" ACC (OfficialAddress.
> > Details)
> > Address = Object Class of of "Inner" ACC (OfficialAddress. Details)
> >
> > The same concept would apply for "Person. Residence. Address". In an
> > earlier e-mail today (subject: "ASCC Names"), I posed the question of
> > whether or not the above names should be stored as Slots (or a single
> > Slot) on the Association that links the ACCs, or not.
> >
> > According to the CCTS spec, the name ASCC "Person. Official. Address"
> > would have the following 11179 terms:
> >
> > Object Class = Person
> > Property Term = Official
> > Representation Term = Address
> >
> > So you see, there is no need for us to store/maintain the above terms,
> > because one can "derive" the name of the Association based on the data
> > element terms for the "outer" and "inner" ACCs. Why store information
> > more than once?
> > </JMC15>
> >
> > > BTW, I'm saying we should worry about sintax binding.. just that we
> > > cannot cut things that CCTS defines and sintax binding
> > > implementers use. We (regrep+cc) are the bridge between this 2.
> >
> > <JMC15>
> > As I've stated *multiple* times, the OASIS/ebXML Registry TC was not
> > brough into the process of creating the CCTS spec. Therefore, we have
> > the right - and we *will* usurp it - to interpret the CCTS spec in any
> > way in which we choose. I have raised up to Patrick Gannon
> > and Karl Best
> > (through Kathryn) the legal issues of our not being 100%
> > compliant with
> > the CCTS spec. That is the field that we're playing on, and
> > that is the
> > field we will continue to play on. Feel free to jump off if you don't
> > like the grass.
> > </JMC15>
> >
> > > Sorry I can't continue anymore for today.
> > >
> > > Cheers,
> > > Diego
> > >
> > > > -----Original Message-----
> > > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > > > Sent: Tuesday, September 02, 2003 8:53 PM
> > > > To: Diego Ballvé; CCRev
> > > > Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
> > > >
> > > >
> > > > Forwarded on behalf of Diego. Please see comments marked
> > with <JMC3>.
> > > >
> > > > Diego Ballvé wrote:
> > > > >
> > > > > Chiusano Josheph wrote:
> > > > > > <JMC2>
> > > > > > We won't need such fields, since we will not be
> > > > representing ASCCs as
> > > > > > entities but rather as Associations (so no
> > dictionaryEntryName, no
> > > > > > propertyTerm, etc.). The CCTS spec is *much* too
> > > > heavyweight on their
> > > > > > representations here - on top of ASCCs being entities, it
> > > > > > also specifies
> > > > > > Association Core Component Properties (more
> > entities!). Yikes!!!!
> > > > > >
> > > > > > So we're getting rid of layers that do not need to exist.
> > > > > > </JMC2>
> > > > >
> > > > > .. and creating new layers to substitute them - that
> > > > > "Address. Details" dicussion, where ACC extends ACC????
> > > >
> > > > <JMC3>
> > > > The case you cite does not involve layers - it is
> > horizontal in nature
> > > > (extension), rather than vertical in nature (layers).
> > > > </JMC3>
> > > >
> > > > > I DO see the point for propertyTerm, propertyTermQualifier and
> > > > > cardinality for an ACC/ABIE's contained properties
> > (from UML POW),
> > > > > regardless if the property is simple (Basic) or complex
> > (Aggregate).
> > > >
> > > > <JMC3>
> > > > I concur.
> > > > </JMC3>
> > > >
> > > > > I can go through the page12 example again but the Address Object
> > > > > being used twice inside the Person Object is the
> > perfect example:
> > > > > once it is the Residence Address, once it is the
> > Official Address.
> > > >
> > > > <JMC3>
> > > > That is a perfectly acceptable (and common) occurrence. A
> > Person may
> > > > have multiple addresses associated with them. Additionally,
> > > > creating/storing/maintaining an entity called "ResidenceAddress.
> > > > Details" allows it to be reused in multiple scenarios. I'm
> > > > not sure what
> > > > the issue is here.
> > > > </JMC3>
> > > >
> > > > > I'll shut up if outnumbered and use that approach only inside
> > > > > Republica, but IMHO we can't drop those fields.
> > > >
> > > > <JMC3>
> > > > Not sure what fields you mean - I was referring to the
> > properties on
> > > > ASCCs/ASBIEs. Since we are not representing these as entities
> > > > (in the CC
> > > > sense) but rather as Associations, these properties are not
> > > > required for
> > > > ASCCs/ASBIEs.
> > > > </JMC3>
> > > >
> > > > Joe
> > > >
> > > > > Diego
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > > > > > Sent: Tuesday, September 02, 2003 7:46 PM
> > > > > > To: Diego Ballvé; CCRev
> > > > > > Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
> > > > > >
> > > > > >
> > > > > > Forwarded on behalf of Diego. Please see comments marked
> > > > with <JMC2>.
> > > > > >
> > > > > > Diego Ballvé wrote:
> > > > > > >
> > > > > > > Chiusano Joseph wrote:
> > > > > > > > <JMC>
> > > > > > > > Not at all - reference [S2]: "Association Core
> > > > Components will be
> > > > > > > > represented as Associations between ACCs, and will not be
> > > > > > > > considered as
> > > > > > > > "first rate" Core Components".
> > > > > > > > </JMC>
> > > > > > > >
> > > > > > > > If I have ASCC and I want to store them in the registry
> > > > > > > > can I still choose our mapping approach?? I hope
> > so. I though
> > > > > > > > the point was to use RIM Association to represent it.
> > > > > > > >
> > > > > > > > <JMC>
> > > > > > > > Yes - see above.
> > > > > > > > </JMC>
> > > > > > > >
> > > > > > > > I propose again (if that is not what we're doing already!)
> > > > > > > > that we store
> > > > > > > > ASCC as RIM Association, use Association.name/Association.
> > > > > > > > description/Association's Slots to store
> > > > CC/CCProperty details,
> > > > > > > > just like we do for BCC.
> > > > > > > >
> > > > > > > > <JMC>
> > > > > > > > Not sure what you mean by "to store CC/CCProperty
> > > > > > details". An ASCC
> > > > > > > > Association will serve to associate 2 ACCs, and
> > > > nothing more. CC
> > > > > > > > Properties will not be represented as entities in our
> > > > > > architecture.
> > > > > > > > </JMC>
> > > > > > >
> > > > > > > Great. No problems here then, I hope.
> > > > > > > I meant the fields that CCTS attributes to ASCC/ASCCProperty
> > > > > > > (i.e, ASCC.dictionaryEntryName,
> > ASCCProperty.propertyTerm,..).
> > > > > >
> > > > > > <JMC2>
> > > > > > We won't need such fields, since we will not be
> > > > representing ASCCs as
> > > > > > entities but rather as Associations (so no
> > dictionaryEntryName, no
> > > > > > propertyTerm, etc.). The CCTS spec is *much* too
> > > > heavyweight on their
> > > > > > representations here - on top of ASCCs being entities, it
> > > > > > also specifies
> > > > > > Association Core Component Properties (more
> > entities!). Yikes!!!!
> > > > > >
> > > > > > So we're getting rid of layers that do not need to exist.
> > > > > > </JMC2>
> > > > > >
> > > > > > > Diego
> > > > > >
> > > > > > 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