OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]