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

[Dave Welsh <dmwelsh@microsoft.com>]

Please also keep in mind that besides core components support we will
have a need by the registry for the same intrinsic support for the
actual Business Process models: 
SELECT *
FROM BusinessProcesses
WHERE IndustryDomain='Retail', BusinessArea='Identification',
BusinessArea='Procurement', BusinessProcess='Provide Catalog;

We have a separate Business Process team (Catalog Common Business
Process Catalog Project) who have a charter, for the last year now, to
produce a Technical Report in the area of the Library of Business
Process services we'll be needing support on. 
When this team has completed their Technical Report, we'll be sure to
get it to the Registry Team for review/discussion.

Thanks very much
Dave Welsh
UN/CEFACT TMG Business Process Work Group Chair




> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Friday, February 14, 2003 11:15 AM
> To: David RR Webber - XML ebusiness
> Cc: OASIS Registry List
> 
> 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>