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


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

Hi:

My initial thoughts with regard to the queryn proposal were for a *preprocessing* step to recover the query string from query fragments which would then be placed within the standard SRU parameter "query".

It now seems that we are inclining towards query-specific parameters which will hold the query (either complete or fragmented) and that based on a queryType a query string will be constructed for parsing, rather than having a preprocessing step, per se. That is, as I understand it the query does not need to be read from a "query" parameter as such.

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.
       
        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.
       
        3. We still have not discussed how a server can advertise which queryTypes it supports (presumably through the explain facility).
       
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.

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.

Tony




-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Wed 12/29/2010 3:14 PM
To: 'OASIS SWS TC'
Subject: RE: [search-ws] generalizing cql-form to parameterized queries

I actually thought Ralph's solution was rather elegant and  simpler than
mine, and I don't see that it destabalizes SRU.  Could you elaborate?
--Ray



From: Hammond, Tony [mailto:t.hammond@nature.com]
Sent: Wednesday, December 29, 2010 8:50 AM
To: Denenberg, Ray; OASIS SWS TC
Subject: RE: [search-ws] generalizing cql-form to parameterized queries





No, I am not comfortable with this. I think we are moving this all too fast.
And it risks destabilizing SRU.

Maybe we need to reconsider what the purpose of SRU is and what is the
balance across operations.

This push to create a separate CQL parameter set is potentially disturbing.
I was only ever focussed on a preprocessing.

Tony




-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Tue 12/28/2010 9:54 PM
To: 'OASIS SWS TC'
Subject: RE: [search-ws] generalizing cql-form to parameterized queries

Ok moving forward with this, assuming Ralph's approach....

 The parameter 'query' will be struck from the SRU specification. (It will
need to be added to the cql spec, as the one parameter that cql imposes on
an SRU request, but it need not be mentioned in the SRU protocol. Except
perhaps as a commentary, but not in the parameter tables.)

The parameter queryType, if omitted from an SRU request, it's value is
assumed to be 'cql'. If included, it may be 'cql' or it may be some other
query type.

Whatever the query type is, cql, cql-form, or some other query type, there
will be some specification for that query type which will indicate one or
more parameters that will be included on an SRU request.

And as I suggested earlier: Every query type (other than well-known querie
types, e.g. 'cql') will need a URI and in  explain you assign it a short
name that is to be used in the queryType parameter when accessing that
server.

Everyone agree with all this?

--Ray


> -----Original Message-----
> From: LeVan,Ralph [mailto:levan@oclc.org]
> Sent: Tuesday, December 28, 2010 3:45 PM
> To: OASIS SWS TC
> Subject: RE: [search-ws] generalizing cql-form to parameterized queries
>
> Why do we need this?
>
> SRU defines the optional parameter queryType.  SRU has a distinguished
> queryType, CQL.  When queryType is absent, its default value is CQL.
> SRU no longer defines the query parameter.
>
> Every queryType defines the parameters it needs.  CQL defines the query
> parameter.  Cql-form defines an open-ended raft of parameters.
>
> I see no value in the concepts of parameterized and string queries.
>
> Ralph
>
> -----Original Message-----
> From: Denenberg, Ray [mailto:rden@loc.gov]
> Sent: Tuesday, December 28, 2010 2:57 PM
> To: 'OASIS SWS TC'
> Subject: [search-ws] generalizing cql-form to parameterized queries
>
> These are the changes to SRU, as I see it, to accommodate cql-form.
> Please comment, as I want to write this into the draft I am working on.
>
>
> The specific name CQL-form need not be mentioned in SRU (except perhaps
> by example), however we do need to generalize it, for other similar
> query types that come in parameterized form and we need a name for this
> generalization so that we can talk about it in SRU.
>
> Can we call it "parameterized query"?
>
> So there will be a class of queries distinguished as Parameterized
> Queries. CQL-forms will be in this class. Thus, two classes of queries
> 'string' and 'parameterized'.   (Hopefully we won't later discover that
> we need yet a third class.)
>
> I think every query (other than well-known) will need a URI and in
> explain you assign it a short name that is to be used in the queryType
> parameter when accessing that server. That would mean, for example then,
> that CQL-Forms is just a local name anyway (unless we decide it is
> well-known).  And you indicate in the explain file whether the query is
> of class 'string' or 'parameterized'.
>
> Thus for any request
>
> - If there is a query parameter:
> The query is of class 'string', and the value of the query parameter is
> the query string. The parameter queryType will be included if the query
> is of type other than cql and may be omitted or included for a cql
> query but in any case it will be of class 'string'.
>
> - If there is no query parameter:
>  The query is of class 'parameterized'. The queryType parameter MUST
> occur and there MUST be one or more parameters in the request as
> specified by the specification for that query.
>
> Anything else?
>
>
> --Ray
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




****************************************************************************
**** 
DISCLAIMER: This e-mail is confidential and should not be used by anyone who
is
not the original intended recipient. If you have received this e-mail in
error
please inform the sender and delete it from your mailbox or any other
storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail
or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan

Publishers Limited Registered in England and Wales with registered number
785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS 
****************************************************************************
****




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