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

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

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
>