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

[Chiusano Joseph <chiusano_joseph@bah.com>]

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?

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>

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano