Actually the proposal originally put forward was to allow individual providers to 'pre-bake' common queries for any sub-domains they support that might make use of them, that are too complicated or difficult to write using the simple query syntax.
When it comes to UI invoked queries, the existing specification for UI delegation (selectors) should be sufficient for individual providers to offer specialized queries predefined by the provider. The client simply need to chose that particular exposed UI selector from the services provider document. What this proposal is all about is providing pre-defined queries, that the individual providers knows will be useful, without having to make it a part of the OSLC specification, and providing a generic consistent way for clients to invoke programmatically. The main motivation for this proposal is to provide a mechanism for executing queries that the simple query syntax can't handle, and/or queries that would require detailed knowledge of the internal storage structure if a generic (ie. SPARQL) service would require. In the original write up I intentionally (as Ian hinted) tried to separate it from the existing simple query Answering Ian's comments here (appologies Andy) is what you propose adequate to replace the CALM filters defined on jazz.net? (does it need to be?) Possibly. In a way this proposal is placing parameters on these filters. I wouldn't go as far as to suggest that this could replace CALM filters yet. I'd like to see how the proposal shapes itself first. how about delegated UI that allow new predefined queries to be created? I think the existing UI delegation spec for selectors certainly permits this, and when it comes to providing a UI for clients that executes pre-defined queries the existing standard works for me. It isn't sufficient when it comes to non-UI clients. the resource that is POSTed to execute a query could be described by an OSLC Resource Shape - this is an interesting notion that I played around with a little. maybe I dropped that path too early. I guess I was afraid of the potential to have very hard to construct resources as parameters, and the requirements on the client to assemble them and present to the user (if need be). I also agree that there is nothing AM specific in here. As soon as we talk over the proposal and ensure it is a good thing for our domain, I'll propose it formally to the core. <jim/> jim conallen CAM Lead Architect, OSLC AM Lead [email protected] Rational Software, IBM Software Group From: Andrew J Berner/Dallas/IBM@IBMUS To: [email protected] Date: 02/02/2011 02:03 PM Subject: [oslc-ArchMgmt] More on Predefined queries Sent by: [email protected] In response to Jim's proposal for pre-defined queries, Ian Green wrote: >>how about delegated UI that allow new predefined queries to be created? There are two different capabilities related to "pre-defined queries"....Jim's proposal I believe was to include some specific queries in the spec. Then a client would use that URL for that purpose with all OSLC providers. A second notion is that in general, the tools that are providing these services allow a customer to define queries that customer finds useful and save them by name. The spec can also have an attribute/service that lists these queries...the attribute would be the same for all providers, the data in the list would be unique to each customer. A client uses that through configuration: If the client needs a query for a specific purpose, the customer must create an appropriate query in whatever tool they use as provider, then supply the name of the query through some configuration of the client tool. This is the typical way clients of integrations get specialized data. Then the code the client writes is portable to any OSLC provider, since the query the customer names will show up in the list for the attribute/service. Ian's idea of a delegated UI then makes a lot of sense: When a client tool needs a specialized query to be configured, they can ask the customer to do it through that delegated UI, returning back the URL, and the provider then exposes the parameter formats through the service attribute. I don't see anything "AM" specific about this. I think Ian already pointed to the idea of "filter queries" in some of the Rational products as being the same type of thing. Should this move to OSLC Core? Andy Berner _______________________________________________ Oslc-Am mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-am_open-services.net
