RE: [search-ws] cql-form issues checklist

["Hammond, Tony" <t.hammond@nature.com>]

Title: RE: [search-ws] cql-form issues checklist

Hi Ray:

Please note that I am out of the office until the new year and have limited access to email so am not able to fully participate in the discussion.

Anyway, my comments (inline) to your summary notes below.

Tony



==
> 1.  There will be a queryType for cql-form (see point 2 regarding the name). There also should be prose within the SRU spec that for certain queryTypes, there will be no query parameter (and thus the query parameter becomes optional), and instead, the query will be expressed as parameters within the SRU request, and the parameter names will be defined by the specification for that queryType.

I am concerned about this. We have decided in SRU 2.0 to use presence of query parameter as signal for searchRetrieve operation. That rule could be amended to presence of query *or* queryType parameter, but this starts to get real messy. So should we:

        a. reinstate operation parameter [no]
        b. use presence of query *or* queryType [maybe]
        c. require query but with some placeholder value if query elsewhere [maybe]
       
The idea in c) is that the query is aleady present but just has to be composed. So one could have something like

        query=NULL
       
or some better non-query value than NULL which would be replaced by the query builder. Reason for looking for a set value is to force the inclusion of the query parameter which might otherwise be dropped by a smart browser.

I must say that I don't like b). I prefer c) with appropriate value.

Btw, we must be careful to use language that does not suggest there is a fixed set of queryType parameters. For cql-form proposal we are proposing a family of parameters which could have multiple (unrestricted) members.

> 2. The queryType name for this "thing" we are talking about could be: cql-form, or cql-p (for "cql parameterized") or any of a number of things. Let's call it cql-form for now because that's what we have been calling it - that may not be the best name -  we can decide later what the real name will be.  I think cql-p would be fine.  I don't have a strong opinion. So, in all that follows substitute whatever new name we come up with for cql-form.

I don't like cql-p. Too cryptic.

I would prefer cql-form. I also suggested cql-lite but see that might not be liked. Another alternative would be something like cql-simple. I do prefer the generality.

> 4. When queryType=cql-form then there is no query parameter and there will be parameters in the SRU request as defined by the cql-form spec.

Could be a query parameter - see comments above. But agree with where you're going with this in defining queryType-specific extension parameters. Note also my comment about not restricting to a given "set" or "number" of parameters. In the present case we are suggesting a parameter family.

> 3. One of which will be a queryN parameter (defined by the cql-form query spec -that is, not defined by SRU).  Its value is a positive integer which is greater or equal to the number of search clauses. It is not overloaded with any other meaning.

I very much prefer lowercase form - queryn. Will be much easier not to introduce any case sensitivity into the parameters. As long as it is case insensitive one can refer to queryN in examples but even then I think that is poor form.

I still incline to my proposal for a signed value - see comments below. Regard the sign not as overloading but as additional subfield if you like.

> 4.  There do not need to be different query types for preceding and following boolean style clauses, as discussed yesterday. Are we agreed on that point?

No - I disagree. I think there will be users who prefer one form or other. I think we could "get away" with one canonical form but see little reason to restrict ourselves. I have shown how this can be easily done. For those who don't care we have the default case where queryn ios positive. For those who do care they have the option to use a preferred boolean form.

I don't understand the objection here. There is no processing overhead to speak of. We are not overloading but providing a well known compsci pattern to allow alternate forms to be expressed. I definitely would object to using different queryTypes for alternating booleans - that really is OTT.

> 5.  The naming convention for the parameters are still to be decided.

OK. I have made my proposal for concise forms q[irtb]{n}. Logically a q{n}[irbt] form would be better but a little more fiddly to process. The q{n} form corresponds better to a series representation:

  query = q1* + q2* + q3* + ...

Again I would stress we are dealing with a URI querystring and not an XML document and so brevity is a watchword.

> 6. I propose that the cql-form spec be a normative annex of the cql spec.

That makes sense to me.

On this point I was surprised to see no comment (unless I missed it) on my revised BNF. This was not any attempt to get a support in a parser but just an exercise to show the actual restrictions on CQL that we were considering.

I am still concerned that we have not spelled out clearly enough just what CQL forms are allowable. The BNF was an attempt to generalize a coherent and well-defined subset of CQL: no nesting, no modifiers, no prefix assignments, no sort order (although this latter maybe could be added in). So a linear CQL without the frills.

We do need to deal with the question of default index/relations.

And I think grouping is definitely to be excluded.

This stripped down CQL corresponds very well to the flat nature of web forms.

==


-----Original Message-----
From: Denenberg, Ray [mailto:rden@loc.gov]
Sent: Tue 12/21/2010 1:59 PM
To: 'OASIS SWS TC'
Subject: [search-ws] cql-form issues checklist

Following is my summary of the state of resolution of the cql-forms issues. Please address these point by point.  And note if there are issues I haven't covered.

1.  There will be a queryType for cql-form (see point 2 regarding the name). There also should be prose within the SRU spec that for certain queryTypes, there will be no query parameter (and thus the query parameter becomes optional), and instead, the query will be expressed as parameters within the SRU request, and the parameter names will be defined by the specification for that queryType.

2. The queryType name for this "thing" we are talking about could be: cql-form, or cql-p (for "cql parameterized") or any of a number of things.
Let's call it cql-form for now because that's what we have been calling it - that may not be the best name -  we can decide later what the real name will be.  I think cql-p would be fine.  I don't have a strong opinion.
So, in all that follows substitute whatever new name we come up with for cql-form.

4. When queryType=cql-form then there is no query parameter and there will be parameters in the SRU request as defined by the cql-form spec.

3. One of which will be a queryN parameter (defined by the cql-form query spec -that is, not defined by SRU).  Its value is a positive integer which is greater or equal to the number of search clauses. It is not overloaded with any other meaning.

4.  There do not need to be different query types for preceding and following boolean style clauses, as discussed yesterday. Are we agreed on that point?

5.  The naming convention for the parameters are still to be decided.

6. I propose that the cql-form spec be a normative annex of the cql spec.

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

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