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: cql-form issues checklist


OK, How about this suggestion to address some of Tony's concerns:

We keep the current situation that the searchRetrieve operation is triggered by the presence of a parameter called query (personally, my preference has always been to have one operation per end point but that's another argument which I'll concede I lost!)

We modify the specification such that a queryType can define *additional* parameters to the query parameter for passing the query data (rather than alternative parameters).

For queryType=cql, the entire query is passed in the query parameter

For queryType=cql-form, the number of parameters (and possibly the location of Booleans) is passed in the query parameter (i.e. we use the query parameter for the data discussed for queryn), and the terms are passed using parameters q[r|t|b]<n>

Matthew


> -----Original Message-----
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: 22 December 2010 11:42
> To: Denenberg, Ray; OASIS SWS TC
> Subject: 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
> **********************************************************
> **********************


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