[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
Forwarded on behalf of Diego. Please see comments marked with <JMC17>.
Diego Ballvé wrote:
>
> > 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".
>
> You are right. No BBIE. But ASBIEs(ASCCs) also have PropertyTerm.
<JMC17>
Absolutely, with our common understanding (a reminder for us all, myself
included) that ASBIEs/ASCCs will be represented in our architecture as
Associations. So when we refer to the Property Term, it doesn't mean
that ASBIEs/ASCCs are represented as entities (i.e. they are not
represented as ExtrinsicObjects as BCCs and BBIEs are). I mention this
only because BCCs have Property Terms according to our interpretation of
the CCTS spec.
</JMC17>
> Because ASBIEs(or actually the referenced ABIEs) serve as complex
> properties for aggregates.
>
> That example references Address ABIE twice, with 2 different
> PropertyTerms, but 1 type definition: "US_Address. Details"
>
> > 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.
>
> Watch out for Assembly process. I prefer to call assembly
> the process of creating BIEs from CCs, and sintax-binding
> the process of creating XML/EDI/whatever from BIES..
<JMC17>
You're absolutely right - I was trying to be concise in terminology, but
instead I mixed concepts. I'll refer to the entire process as
"Assembly/Serialization" in the future. Please let me know if you prefer
a different term, so we can be consistent in our terminology (I think
we're creating an Ontology here!).
</JMC17>
I believe I'm aligned with CCTS on that.
>
> I don't mind creating the name on the 2nd stage, sintax-binding,
> as you suggest. But in order to do that, ASBIE's PropertyTerm
> and Qualifier must be available (= stored in a Slot, in the RIM
> Association). Do we agree on that???
<JMC17>
Not at all. There is another approach that I've asked that we consider -
that is, that we do not store any ASCC/ASBIE terms on the Association
itself, but rather allow the Assembly/Serialization process to extract
them from the various entities ("outer" ACC/ABIE, "derived" ACC/ABIE),
as described in the previous e-mail in this thread. This would allow the
registry to avoid duplicate storage of data element terms, and to have
to sync the terms if a change was made to any term.
I'd like to also hear from other Team members on which approach they
believe is best.
</JMC17>
If so, I'm more than happy.
> I don't want ASCC/ASBIE as entity, if you mean ExtrinsicObject,
> RIM Association is perfect for me.
<JMC17>
Great - I mean RIM Assocation.
</JMC17>
> Tks,
> Diego
>
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Thursday, September 04, 2003 4:50 PM
> > To: Diego Ballvé; CCRev
> > Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
> >
> >
> > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]