OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] generalizing cql-form to parameterized queries


> That is, as I understand it the query does not need to be read from
> a "query" parameter as such.

Exactly.


> My concerns with dismissing query parameters as not being an
> integral part of SRU is threefold:
>
>       1. The query parameters are not an actual part of the query
>       language but rather are part of the SRU query facility. They
>       are in fact SRU parameters which get allocated dynamically
>       based on queryType.

We're changing that.  Now, the parameter(s) that carry a query are not defined by SRU, but are defined by the queryType.

       
>        2. By generalizing this queryType notion there will be
>       additional overhead in documenting which query parameters
>       are associated with which queryType and how they function
>       to produce a querystring.

Every queryType will need documentation.  The extra bit to define the parameter(s) that carry the query will be the most trivial part of the documentation.

The comment about producing a querystring sounds like you are focused on cql-form, where the parameters do indeed get turned into a CQL query string.  Other queryTypes, such as Google's, have multiple parameters that will not be turned into a CQL query.l

       
>        3. We still have not discussed how a server can advertise
>        which queryTypes it supports (presumably through the
>        explain facility).

TBD
       

> I am a little worried too that some may consider supporting only
> the classic CQL query function and paying lip service to this more
> elaborate approach which would now be an integral part of the
> SRU processing.

I'd be in the camp with no interest in supporting anything other than classic CQL. (Today anyway.)  I don't see a problem with that.


> So, whether this is treated as a preprocessing step or a queryType
> specific processing step I think this needs to be recognized within
> the SRU processing model.

I agree that the cql-form documentation must absolutely address the processing necessary to convert an array of q** parms into a CQL query.

Currently, the SRU model is silent on query processing and database interactions.  If we were to add anything, it would simply be to acknowledge that the query parameter(s) (along with sort parameters) are passed through to a database interface layer which is responsible for processing the query and returning abstract records.  Personally, I don't think we need to do that.

Ralph



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]