OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [regrep] Summary: Implementing CCTS in Registry


Farrkh,

Thanks - I'll incorporate this into the summary (without resending) by
specifying "binding/query updates" rather than an additional option.  In
this way, we can think of these collectively as "some way of handling
Core Components in the registry without RIM updates".  Hope this is ok
with you.

Thanks,
Joe

Farrukh Najmi wrote:
> 
> 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
> >>
> >>

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