RE: [search-ws] error in sort parameter

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

Title: RE: [search-ws] error in sort parameter

But do we still need to note a caution about index names that can be used with this syntax? The example I gave is a legitimate index name which cannot be used here with "sortKeys". As I noted earlier it may be sufficient just to note under index names that some names are more restricted in their application.


Tony


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

Yes you're right the  space still needs to be escaped, I think  my
discomfort is with the idea of prescribing a space in the middle of a
parameter and the fact that I can get away with it in a URL bar if it occurs
inside of quotes.   This is probably not rational of me.



And, since this is the way it was earler in 1.1 (we dropped it in 1.2 and
revived in now in 2.0)  I'll drop this and we'll just leave it as is, so
nevermind.



--Ray



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



Hi Ray:

Am I missing something? What has quoting the string got to do with anything?
The space still needs to be %-escaped. If you want to avoid that then you
would have to introduce an alternate delimiter for sort indexes - say ";".
But this (and also the "," char) are anyway compromised by the wide-ranging
name production. Here's an example of an index name "inde,x" which can't be
used reliably with the "sortKeys" spec:

% cql "inde,x=3"
<searchClause>
  <index>inde,x</index>
  <relation>
    <value>=</value>
  </relation>
  <term>3</term>
</searchClause>

I guess we ought to note that some names for indexes are more robust than
others, or less fragile maybe.

Tony


-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@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.hammond@nature.com]
Sent: Monday, December 06, 2010 11:02 AM
To: Denenberg, Ray; OASIS SWS TC
Subject: RE: [search-ws] error in sort parameter





> Which is an error; the parameter value includes a space and thus should be
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.

Tony






-----Original Message-----
From: Denenberg, Ray [mailto:rden@loc.gov]
Sent: Mon 12/6/2010 3:27 PM
To: 'OASIS SWS TC'
Subject: [search-ws] error in sort parameter

Let me call attention to a problem with the SRU 2.0 sort parameter. (I
noticed this while researching the facetLimit situation, which I will post
further discussion on later.)

Look around line 623-624 of the September 21 version, in section 9.2
Serialization, it says

    An example of the sortKeys parameter in an SRU URL might be:

     &sortKeys=title,onix date,onix,,0


Which is an error; the parameter value includes a space and thus should be
enclosed in quotes:

     &sortKeys="title,onix date,onix,,0"

And a rule should be added to the serialization bullets to this affect:

probably: "if there is more than a single key, the entire parameter value
should be enclosed in quotes."


However, note the fourth bullet:
*       The path and schema must be quoted if they contain quotes, commas or
spaces. Internal quotes must be escaped with a backslash.

Probably should add to this:

"When the sort parameter has multiple keys and thus is enclosed in quotes,
then any quotes in the path and scheme, including enclosing quotes, must be
escaped."    (Or would that go without saying?)

Do you concur?

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




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