[oslc-ArchMgmt] More on Predefined queries

James Conallen jconallen at us.ibm.com
Wed Feb 2 14:25:18 EST 2011


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
jconallen at us.ibm.com
Rational Software, IBM Software Group





From:	Andrew J Berner/Dallas/IBM at IBMUS
To:	oslc-am at open-services.net
Date:	02/02/2011 02: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/20110202/49c78d5b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110202/49c78d5b/attachment.gif>


More information about the Oslc-Am mailing list