My $0.02 -- this is an OSLC core issue. We once discussed this, at least within IBM, and semi-jokingly referred to these delegated query-building UIs as "URL calculators." This was based on the assumption that the caller of the delegated query-builder would get back an URL; a GET on that URL would then produce the paginated query result. An advanced client might have knowledge of how a query is encoded into an URL, and could (in principle) have its own query builder, but that would likely be outside of the scope of an OSLC spec. A simple client would call the delegated query builder, and get back an URL.
The response to a GET on one of these URLS should structurally be the same as the response to a GET on a predefined query URL. What's not clear to me is if the spec should identify specific predefined queries, or if it should include a way of getting a list of the queries that a service provider offers. Regardless, it is also likely that these queries should exist within a "context" of some kind (what many tools would call a project). Perhaps the query-builder also starts with a predefined context against which the query runs. My thinking could well be out of date here, but this makes sense to me. Thanks, ~~~Steve -- Steve Abrams STSM, Rational CTO Team IBM Software Group From: Andrew J Berner/Dallas/IBM@IBMUS To: [email protected] Date: 02/02/2011 08: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
