[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts
Chiusano Joseph wrote: ><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! > Actually, I was suggetsing an ebRS spec change in the query chapter to address this in ebXML Registry as a generic feature that works just as well for OGC Map objects and HL7 ConformanceProfile objects.... The key point is that we handle the requirement generically rather than specific to CC and benifit from it in all other use cases besides CC. > >- 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 >> >> -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC