[oslc-ArchMgmt] More on Predefined queries

[Steve Abrams]

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 at IBMUS
To:
oslc-am at open-services.net
Date:
02/02/2011 08:03 PM
Subject:
[oslc-ArchMgmt] More on Predefined queries
Sent by:
oslc-am-bounces at open-services.net




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
Oslc-Am at open-services.net
http://open-services.net/mailman/listinfo/oslc-am_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110203/ace6a609/attachment-0003.html>