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

[Matthew Dovey <m.dovey@jisc.ac.uk>]

Any explanation for the objection.

This approach does not break any existing applications, keeps the requirement for the query parameter to indicate the searchRetrieve operation.

Modifying the spec such that queryType can indicate additional parameters to query, seems no worse than modifying the spec so that queryType can indicate alternative parameters to query.

How the server interprets anything passed in the query parameter is entirely dependent on the value of queryType so no change there.

Matthew

> -----Original Message-----
> From: LeVan,Ralph [mailto:levan@oclc.org]
> Sent: 22 December 2010 16:36
> To: Hammond,Tony; Denenberg, Ray; OASIS SWS TC
> Subject: RE: [search-ws] RE: cql-form issues checklist
> 
> No.
> 
> Ralph
> 
> > -----Original Message-----
> > From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> > Sent: Wednesday, December 22, 2010 6:51 AM
> > To: Hammond,Tony; Denenberg, Ray; OASIS SWS TC
> > Subject: [search-ws] 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
> > >
> **********************************************************
> > > **********************
> >
> > ---------------------------------------------------------------------
> > 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