Re: [search-ws] [Issue] Need to support parameterized stored queryinvocation

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

Here are a summary of what I find important observations related to the 
discussion surrounding Parameterized Query (PQ) discussion spec:

*Similarities between SRU and PQ*

    * The abstract model in PQ spec is pretty much the same as the
      abstract model behind SRU spec. This is by design and not accident.
    * The concrete HTTP binding for the request is nearly identical but
      for the fact that PQ spec fixes some minor REST violation as
      discussed in
      <http://www.oasis-open.org/apps/org/workgroup/search-ws/email/archives/200710/msg00046.html>
    * The SOAP Binding for request should be identical since there are
      no REST issues
    * The OpenSearch binding is nearly identical if my proposed draft
      chapter is accepted

*Differences between SRU and PQ*

    * SRU does not explicitly declare an Abstract Interface and Model.
      This makes it harder to recognize common ground and get us bogged
      down in specific bindings to representation formats.
    * The two specs are significantly different when it comes to default
      canonical response format. PQ proposes using ATOM 1.0 while SRU
      proposes to keep current SRU Response format. It is important to
      note that the underlying abstract model is pretty similar. I have
      shared my rationale for ATOM as default canonical responseFormat
      in
      <http://www.oasis-open.org/apps/org/workgroup/search-ws/email/archives/200710/msg00068.html>
    * Another significant difference is in the query invocation model.
      SRU using CQL while PQ uses Parameterized Queries. It is possible
      to express CQL query as a Parameterized Query. It is also possible
      to support parameterized query through stylized use of CQL.

*Summary of Issues*

    * Our issues can be divided into following buckets:
          o Issues related to Abstract Interface. We mostly have
            agreement here. The only issue is what is our Query
            Invocation Model. Do we use CQL as a special case of PQ or
            do we use PQ as a special case of CQL
          o Issues related to concrete XML Schema binding. A major issue
            here is whether to use ATOM as a default canonical
            responseFormat
          o Issues related to HTTP GET and importance of REST. The
            issues here are minor. However, there seems to be a lot of
            skepticism regarding REST with some members


More inline below...

Ray Denenberg, Library of Congress wrote:
> I've skimmed through the document, and though I probably need to look at it
> more carefully, I do have a couple initial observations.
>
> First, it seems to me that Parameterized Query is easily realized via the
> existing spec.
>
> Consider the example request:
> http://example.com/search?queryId=<someid>&name=japan
>
> It could instead look like:
> http://example.com/search?query=queryId=<someid>&20 and&20 name=japan....
>
> and mean the same thing. That is, queryId can be defined as an abstract
> index with semantics appropriate for parameterized query.
>   

I agree that parameterized queries could be supported by the CQL-based 
SRU Query Invocation Model by defining an abstract index for 
Parameterized Query (the generic concept not a specific parameterized 
query). We could then specify query parameters as "terms" in a predicate.

However, this would require some special implicit rules:

    * A server MUST recognize the parameterized query term as a special
      case and handle it differently from all other terms
    * A client MUST not specify anything more than predicated where
      terms only use "=" and boolean operators only use "and"

IMHO, These implied special case semantics and constraints are 
indicative of an unstable design for supporting parameterized queries.

In comparison, if we used the PQ Query Invocation Model then there are 
no special cases for server or client implementations. The reason is 
that the PQ model is one where each query is essentially a parameterized 
search algorithm that returns a response. CQL fits very nicely as 
another search algorithm.

IMHO, the PQ Query Invocation Model takes away nothing from SRU Query 
Invocation Model while making it more general, flexible and extensible. 
The impact on existing SRU implementations should be quite minor since 
they need not implement any other parameterized query other than CQL and 
any other canonical queries we agree to add to the spec (e.g. FindById, 
FindByKeyWords queries).

What do folks see as a down side of using the PQ Query Invocation Model?

> Next, table 1 makes some challengeable assertions:
>
> - That CQL doesn't support keyword search. CQL certainly supports keyword
> search  

Sorry for my misunderstanding. Can you please refer me to spec section 
on how?

> - That PQ Responses may include non-XML records in standard manner, while
> with CQL it cannot.  The issues of PQ vs. CQL and binary representation are
> orthogonal.
>   

I see it as an important issue. PQ spec allows non-XML content to be 
returned in a standard manner while SRU leaves it up to applications.

> - That CQL expects the server to maintain state between client requests.
> We've already established that this isn't true, and in any case, as above,
> it is an orthogonal issue.
>   
We agree that the behavior is optional. My point was that the SRU spec 
encourages REST violation in this area
I do agree that it is somewhat orthogonal to the main differences.

> - PQ Supports ATOM Binding, while CQL doesn't.  Similarly orthogonal.
>   

I think this is a major difference. For HTTP GET PQ requires no schema 
for requests and relies on ATOM Schema for response.
The SRU colleagues have not yet agreed that ATOM as default canonical 
responseFormat is acceptable. I see this as a major
difference of substance with long term ramifications.

> - Supports Open Search Binding.  Similarly.
>   

With my recent contribution we can scratch this as a difference :-)

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com