[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]