[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC