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

["LeVan,Ralph" <levan@oclc.org>]

The query parameter is defined by the CQL queryType to carry a CQL
query.  We shouldn't decide that now it carries other stuff when the
queryType is not CQL.

It is clearly the case that the queryType defines what parameters carry
the query.  The SRU standard does not define that anymore.  Therefore,
SRU behavior based entirely on the presence of the query parameter is
broken.

There is an opportunity for a slight finesse here.  If we say that CQL
is the default queryType (and my vote is for a non-mandatory queryType),
then there's room for SRU to talk about the query parameter when the
queryType is CQL.  Which gets us back to my choice: either queryType or
query can signal a searchRetrieveRequest.

Ralph

> -----Original Message-----
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> Sent: Wednesday, December 22, 2010 2:07 PM
> To: LeVan,Ralph; Hammond,Tony; Denenberg, Ray; OASIS SWS TC
> Subject: RE: [search-ws] RE: cql-form issues checklist
> 
> 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
>