-----Original Message----- From: Ray Denenberg, Library of Congress [mailto:rd...@loc.gov] Sent: Mon 12/6/2010 4:24 PM To: Hammond, Tony; 'OASIS SWS TC' Subject: RE: [search-ws] error in sort parameter

I'll get to the facet issues next message .

You can't have a space in an SRU parameter because it goes directly into a URL. That's the reason you can't have a space in a cql string, because it's an sru parameter.

You can have the space but you have to url encode it. Why would we want to prescribe spaces that have to be url encoded?

--Ray

From: Hammond, Tony [mailto:t.ha...@nature.com] Sent: Monday, December 06, 2010 11:02 AM To: Denenberg, Ray; OASIS SWS TC Subject: RE: [search-ws] error in sort parameter

enclosed in quotes:

Don't see why.

This is an SRU parameter value - not a CQL string. AFAIK spaces are valid in querystring parameter values.

But this does bring up a related point in the "facetLimit" proposal I put forward because this has a value which *is* a CQL string and thus not like SRU "sortKeys". (The CQL "sortby" parameter is however OK and does not restrict index values.)

The "facetLimit" proposal does restrict index values. There would seem to be only two options here:

1. to change the two delimiter chars to any chars not allowed by the "simple-string" production

"()/<=>

(But this does make for clunky syntax.)

2. to accept that there is a restriction on index names and to add a note under index names that care should be exercised in naming so that conflicts such as use in "facetLimit" would be avoided

In my view it is regrettable that names in CQL have been allowed to range so widely because (as here) it makes it difficult to fence them in when needed.