RE: [search-ws] Call Monday, January 10; cql-form options

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

> Sorry, I've completely lost track of what problem we're trying to solve
> here.
> 
> Ralph

We're trying to solve the cql-form problem.   Where we left of (before my
message yesterday) was that Tony had suggested that he wanted it modeled in
terms of pre-processing.  So that the query would be transmitted via
parameters, i.e. in "form' form, and then the server would convert those
parameters into a cql query, and process it as a conventional cql query.

What we don't understand is: is this conversion (a) supposed to be visible
to the protocol, or (b) is it something that the server is free to do if it
chooses but is invisible to the protocol.

You (Ralph) and I balk at the prospect of (a), and we are not clear what
Tony's position is, but it seems that that is what he is advocating, an
explicit modification to the protocol model to accommodate this conversion.
Tony will have to weigh in.

The other issue was ....

To remove the query parameter or not.  You (Ralph) suggested that we can
eliminate the query parameter and make it a query-specific parameter,
specifically, THE query-specific parameter for CQL.  While I initially went
along with the idea, Tony objected, and I agree with his objection. 

Are you back on track?

--Ray



> 
> > -----Original Message-----
> > From: Denenberg, Ray [mailto:rden@loc.gov]
> > Sent: Thursday, January 06, 2011 5:41 PM
> > To: 'OASIS SWS TC'
> > Subject: [search-ws] Call Monday, January 10; cql-form options
> >
> > We have a conference call Monday morning, January 10.  I will post a
> draft
> > agenda tomorrow afternoon, meanwhile please suggest agenda items.
> >
> > One item for discussion is the cql-form query.  We have the following
> suggested
> > approaches on the table.
> >
> > 1. Ralph's suggestion that query be removed as a first class sru
> parameter.
> > Every query type lists parameters that occur for that query - CQL
> would list
> > 'query' as a parameter.
> >
> > 2. My suggested approach: query remains a first class parameter but
> becomes
> > optional. If the query parameter is included then the query is
> assumed
> to be
> > contained (as a string) within the query parameter. (And if so, if
> queryType is
> > omitted, it is assumed to be a cql query.)  If the query parameter is
> omitted, then
> > queryType must occur and there must be one or more parameters which
> are
> > defined for the query type. (So there is introduced an informal
> distinction
> > between string and parameterized queries, depending on whether the
> query
> > parameter is present.)
> >
> > 3.  Tony's suggestion that there be a preprocessing phase added to
> the
> protocol
> > model.  However this has not been fully articluated, and we really
> need to
> > understand it better.
> >
> >
> > I wish to comment that I had proposed the second approach before
> Ralph
> > proposed the first, at which point I said that I liked Ralph's better,
> but I have
> > changed my mind on that: the problem is, there would need to be some
> way to
> > allow requests where there is no queryType parameter (for
> compatibility).
> > Essentially you want to say "if queryType is omitted then there must
> be a query
> > parameter" but you can't say that because this approach writes the
> query
> > parameter out of the protocol.  I am also sympathetic to Tony's
> observation that
> > writing the query parameter out of the protocol risks destabalizing
> the protocol.
> > So I am back to favoring approach 2.
> >
> > Please comment, and in any case this will be on the agenda for
> discussion
> > Monday.
> >
> > --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
> >
> 
> 
> 
> ---------------------------------------------------------------------
> 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