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

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

From: "Farrukh Najmi" <farrukh@wellfleetsoftware.com>
> *Differences between SRU and PQ*
>
>     * SRU does not explicitly declare an Abstract Interface and Model.

I think we explicitly declared that out-of-scope in the charter.  If we want
to revisit that, it might require that we get a new charter approved.

>     * 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

Can't we  keep these issues separated, the issue of  PQ and the issue of
response format?  The latter is on the table, and we don't have to adopt PQ
in order to adopt the ATOM proposal.

>           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

I'm not sure  there is skepticism about REST, I think there is skepticism
about the assertion that the current model does not adhere to REST.   I
think we are in general agreement (though we need to take this to the SRU
list) about the operation parameter.  I think several of us believe that the
result set model does not violates REST.

But, as in the response format issue above,  these are two separate issues.
If we were to become convinced that our result set model violates rest, and
we wanted to correct that violation, we could do that easily within the
current spec.


> 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

I'm not sure that PQ index would need to be treated differently than other
indexes in this regard.  A server should be able to choose which parts of
the protocol to implement, and use explain to expose what is implemented. If
it chose not to support parameterized query, it would not list the PQ index
in its explain file; if the server recieved a PQ query, it would issue a
diagnostic.

>     * A client MUST not specify anything more than predicated where
>       terms only use "=" and boolean operators only use "and"

Right, but that's what the diagnostic facility is for. PQ is not unique in
that certain combinations of query components do not make sense.

> > - 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?

See A.1 (line 791 if we're aligned), the "keywords" index.



>
> > - 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.

It's an important issue, but I maintain it is orthogonal to the PQ question.
Haven't we sufficiently illustrated that the current model supports binary
representations quite elegantly?


>
> > - 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.

Well we covered this above, but to reiterate, response schema still is
orthogonal to PQ. If we buy into ATOM,  it can be with or without PQ.

Anyone else out there have thoughts on this?

--Ray