Re: [regrep] Summary: Implementing CCTS in Registry

[Farrukh Najmi <farrukh.najmi@sun.com>]

Joe,

I thought the summary was very good.

One thing it missed though was the idea of extending the query 
syntax/semantics to allow for querying a virtual type bu specifying 
objectType rather than ExtrinsicObject and specifying virtual attributes 
instead of slots.

This idea does not suggest that we make change RIM to handle type 
extensibility. Instead it simply allows syntactic sugar in query syntax 
as convenient (more obvious) short hand for the underlying query. This 
would allow a query like:

SELECT * 
FROM CoreComponents
WHERE PropertyTerm='Residence'

as an alternative form for the query:

SELECT * 
FROM RegistryObject, Slots
WHERE RegistryObject.ID=Slots.ID AND
      RegistryObject.ObjectType='CoreComponent' AND
      Slots.Name='PropertyTerm' AND
      Slots.Value='Residence'

The above does not effect how the object is submitted or what it looks 
like when it is returned as a response to a query. It simply makes teh 
query syntax more obvious.

Note that I am not endorsing the above idea but simply want it recorded 
as a more generic and resuable alternative to defining CC in RIM.

-- 
Regards,
Farrukh



Chiusano Joseph wrote:

>Greetings,
>
>Would anyone be willing to comment on the summary below (affirmative or
>otherwise)?  Do we think that it accurately reflects where we stand
>right now, from a high-level perspective?
>
>Thanks,
>Joe
>
>Chiusano Joseph wrote:
>  
>
>>I've taken a shot summarizing the various aspects of this discussion to
>>date, to serve as a sort of "checkpoint" of where we are at.  Below I've
>>listed 5 high-level topics (in no particular order) that I think have
>>grown out of our excellent discussions here, and a very high-level
>>snapshot of where we appear to be regarding that topic.
>>
>>I hope this information is helpful for all, and look forward to feedback
>>on its accuracy.  I will be happy to update this summary as necessary so
>>that we ensure that we capture the picture accurately for all.
>>
>>TOPIC #1 - Representation Within Registry (Intrinsic vs. Extrinsic):
>>
>>- Most seem to favor extrinsic representation, with a defined binding to
>>the registry;
>>
>>- Question remains as to who would create such a binding  our TC, the
>>CCTS Team, or a combination (us consulting to them and them having a
>>liaison on our TC);
>>
>>- Can use Content Management mechanism and create a style sheet indexer
>>for Core Component entities;
>>
>>TOPIC #2 - Context/Assembly:
>>
>>- Can be defined by the CAM TC, as this is their focus;
>>
>>TOPIC #3 - Serialization Format:
>>
>>- Can be defined by our TC(?), perhaps using CRI as a starting point;
>>
>>- David Webbers's "Registry Enabling of Business Metadata Semantics"
>>presentation offers excellent concepts for serialization as well as
>>context/assembly;
>>
>>- CCTS team would not need to be involved in the definition of the
>>seralization format, because they define the syntax-neutral
>>representation of Core Components, not the syntax-specific
>>representations;
>>
>>TOPIC #4 - Core Components Specification:
>>
>>- It is possible that we may request updates to the Core Components
>>specification based on our review of it;
>>
>>- We will need to decide how to communicate our requests to the CCTS
>>Team and work with them toward a solution that is beneficial for all
>>parties;
>>
>>TOPIC #5 - Timing:
>>
>>- Regardless of what Registry specification version this is included in,
>>we believe it would take at least 4 months (probably closer to 6) to
>>define the registry metadata representations (whether intrinsic or
>>extrinsic), context/assembly, and serialization format.
>>
>>- It is still to be determined if this functionality will be included in
>>the Registry V3 specs.
>>
>>Thanks,
>>Joe
>>    
>>