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

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

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

> This is Tony's spec, so he can call it whatever he wants.

This is not "Tony's spec" and not "Nature's spec" either. It's either a best practice for use with posting from forms or nothing at all. It is NOT a documented use case.

And there are still I believe SRU implications in that an SRU processor that can process this queryType would need to execute that additional prepcessing step in order to formulate a query string for parsing.

If we do not recognize that preprocessing step (for queryType) as part of the SRU process then we are back at square one: that forms and SRU are not compatible. Ralph avoids this by shifting the preprocessing to the client. But this - while effective - is not a global remedy.

So, while we can tidy away the extra queryType parameters from SRU there must still be allowance made for an SRU server to carry out preprocessing speending on queryType. Which also brings up a another question: how does a server advertise the queryType's it suports. I believe that is going to have to be in the explain record if it's not already.


> My preference is for the presence of either a query or queryType parameter.  But, if you insist that one of them must be mandatory, then I'd vote for queryType.  According to our new understanding of queryTypes, the query parameter is specific to the CQL queryType, not specific to SRU.  I hate the idea of an empty or meaningless value for a query parameter when a queryType of cql-form is used.

Only comment here is that we cannot make queryType mandatory without breaking many existing SRU implementations.

I do find the "query or queryType" test a little sloppy but I suppose it could be a viable solution.

Tony



-----Original Message-----
From: LeVan,Ralph [mailto:levan@oclc.org]
Sent: Wed 12/22/2010 4:35 PM
To: Denenberg, Ray; OASIS SWS TC
Subject: RE: [search-ws] cql-form issues checklist

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

Yes.


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

This is Tony's spec, so he can call it whatever he wants.  We'll want a
URI somewhere for an unambiguous name and rules for how we turn that
unambiguous name into something short (like we do for context sets.)


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

Yes.


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

Tony seems to like the overloading.  Since I'm going to strongly insist
that this at least be non-normative and prefer that it not be in the
standard at all, I'm not going to insist.  As I said earlier, I think
the forms developers will not be grateful for more options and will
prefer one rule.


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

Tony disagrees.  I don't care.


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

I think Tony is happy with the qtn, qin, qrn, qbn and queryn we've
settled on lately.


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

At best non-normative.  Absolutely published on our web site, but not in
the standard.  We do need to put the rules for creating new queryTypes
into the standard.


> Anything else?

How do we signal a searchRetrieve operation?

My preference is for the presence of either a query or queryType
parameter.  But, if you insist that one of them must be mandatory, then
I'd vote for queryType.  According to our new understanding of
queryTypes, the query parameter is specific to the CQL queryType, not
specific to SRU.  I hate the idea of an empty or meaningless value for a
query parameter when a queryType of cql-form is used.

Ralph


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