Re: [regrep] Implementing CCTS in Registry - further thoughts

[Chiusano Joseph <chiusano_joseph@bah.com>]

<Snip>
However, one can support the use case for the first form without adding 
any extensions to ebRIM and do so generically as follows. We simply 
re-define our query syntax to allow for the first query form and define 
how it maps to extended types (ExtrinsicObject.objectType) and extended 
attributes (RegistryObject.slots).
</Snip>

Yes, an internal "Core Components Gateway" of sorts.  Thanks Farrukh!

- Joe

Farrukh Najmi wrote:
> 
> Chiusano Joseph wrote:
> 
> >Thanks David - that's very valuable information.
> >
> >Regarding our "intrinsic vs. extrinsic" issue - that is, should Core
> >Components and their associatd be represented "intrinsically" in the
> >registry (registry classes of Core Component, Business Information
> >Entity, etc.) or using Extrinsic Objects.  Farrukh and I have had some
> >great discussions about this topic - that is, should we create a
> >"binding" for Core Components (using Extrinsic Objects), or add the
> >pertinent registry classes to the RIM.  The old Software Engineer in me
> >is saying "make this as clean as possible, use an intrinsic approach",
> >while the other part of me is saying "leave it to the
> >implementers...leave it to the implementers...).
> >
> >Having said that, I'd like to put this in generic technical terms so we
> >all can assess it on the same page.  Using SQL queries, I view a query
> >for a Core Component in the intrinsic approach represented as follows
> >(assuming a table named "CoreComponents"):
> >
> >SELECT *
> >FROM CoreComponents
> >WHERE PropertyTerm='Residence'
> >
> >Whereas the same query using a binding with Extrinsic Objects and Slots
> >would look as follows:
> >
> >SELECT *
> >FROM RegistryObject, Slots
> >WHERE RegistryObject.ID=Slots.ID AND
> >      RegistryObject.ObjectType='CoreComponent' AND
> >      Slots.Name='PropertyTerm' AND
> >      Slots.Value='Residence'
> >
> >Certainly not as clean as the first, but probably much easier to
> >implement given the existing RIM.
> >
> >Can someone please confirm my thinking, and correct me if necessary?
> >
> Joe above thinking is correct.
> 
> However, one can support the use case for the first form without adding
> any extensions to ebRIM and do so generically as follows. We simply
> re-define our query syntax to allow for the first query form and define
> how it maps to extended types (ExtrinsicObject.objectType) and extended
> attributes (RegistryObject.slots).
> 
> This could be done with some spec verbiage and some code changes in
> existing impls that would deliver the same result as allowing the first
> query form.
> 
> Thanks for laying it out so nicely the desired and the current situation.
> 
> >
> >Thanks!
> >Joe
> >
> >David RR Webber - XML ebusiness wrote:
> >
> >
> >>I just reviewed the Section 7 of the CCTS spec' again,
> >>and the UML models.
> >>
> >>This is actually significantly simpler from the earlier
> >>UML models that the first CRI work had to tackle.
> >>
> >>I believe the behaviours that are described in Section 7
> >>can be implemented by a combination of:
> >>
> >>1) A new CRI structure to capture the semantic nodes
> >>     that are specifically identified in Section 7
> >>
> >>2) The CAM mechanism to implement the BIE
> >>     mechanisms, cardinality and context mechanisms.
> >>
> >>3) Normal Registry RIM behaviours around
> >>    associations, versioning, unique IDs, classifications
> >>    and so forth.
> >>
> >>4) Datatyping and other physical layer information
> >>    that comes across from the industry dictionaries
> >>    which is of course missing from the CCTS logical
> >>    layer - but is vital for actual payload manipulation.
> >>    This manifests itself as an extension to the CRI to
> >>     provide physical layer details.
> >>
> >>Having said this - its definately not just a "weekend hack".
> >>
> >>I'd say we're lookinig at three to four months of effort to
> >>get this spec'd and agreed to.
> >>
> >>The good news is that I do not at this point see any
> >>need to extend the RIM itself - just show how to
> >>utilize it + excellent XML structures - to deliver the
> >>required behaviours.
> >>
> >>DW.
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >>
> 
> --
> Regards,
> Farrukh

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano