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

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Farrukh,

I like the extrinsic approach.

The approach here below with the explicit SQL table - is the one 
we need to avoid, right?!?

Since the Core Component can be expressed in an XML structure,
you simply store the structure as any other XML, and handle it
just as any other content.   However - under the MIMEtype = XML, 
we have the ability to do properties - and there we state "CoreComponent"
(I believe we already have that implemented).

You can then query against "type" = corecomponent, and whatever
other search string details you need.

Therefore implementors can layer on top  whatever frontend
querying shortcuts they need, all we agree on is the actual XML structure 
that constitutes a "CoreComponent"
so that we have consistency of representation.   Least ways - this was
the CRI approach.

The new wrinkle to the puzzle  is that now you can do collections using
the same approach with OASIS CAM - where the CAM XML captures
all the collection information about the underlying core components
used in the assembly (BIE in CEFACT parlance).  You can then 
do some snazzy things if you want to - like when someone uploads 
a CAM XML document to the registry - it could scan it and 
auto-generate RIM associations based off the collection information 
in the CAM structure - similarly for RIM package information and so on.   
Again implementers could decide how far they want to take these 
convenience features for the end user...

DW.
=============================================================
Message text written by Farrukh Najmi
>>>>
>>>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
>>    
<