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] RE: Facet limit


Title: RE: Facet limit

I’m not going to the mat on this.  I prefer my way, even hearing your counter-arguments Ray.  But it really isn’t important.

 

Ralph

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Tuesday, December 07, 2010 9:25 AM
To: Hammond,Tony; 'OASIS SWS TC'
Subject: [search-ws] RE: Facet limit

 

The fact is that as a practical matter there are currently no repeatable parameters:

 

- As I just pointed out a moment ago httpAccept is not intended to be repeatatble.

 

- The extension parameter may appear repeatable in the table, but really each extension parameter in a given request should look different, so you don't really end up with a repeatable parameter. (Although to be fair, there is no rule saying you can't use the exact same extension twice, and the extension definition would have to say what that would mean.)

 

-Likewise, the facetLimit parameter, while it might appear repeatable, in the current draft it's different parameter strings for different indexes. (Of course that's what we're trying to change now.)

 

So we have two choices, one is to INTRODUCE a repeatable parameter (into a protocol that doesn’t currently have one), the second is to complicate the facetLimit parameter. 

 

My preference is the latter, because we have already complicated the sort parameter.   (If the protocol already had a repeatable parameter, or if sort were not already similarly complicated, then I would prefer the first approach.)

 

Ralph, please weigh in on this.

 

--Ray

 

 

From: Hammond, Tony [mailto:t.hammond@nature.com]
Sent: Tuesday, December 07, 2010 9:47 AM
To: Denenberg, Ray; OASIS SWS TC
Subject: RE: Facet limit

 

Hi Ray:

A couple comments about "facetLimit" - which btw should also apply equally to "facetCount" and "facetStart". (The parameter "facetSort" is global as I understand it.)

    1. I note that the only repeatable parameters in the SRU spec are these listed facet parameters, the extension parameters, and "httpAccept". So there is a question as to whether SRU wants to support repeatable parameters - period. My proposal for "facetLimit" (and similarly for "facetCount" and "facetStart") was for a single (non-repeatable) compound value. I also query what real purpose repeatable "httpAccept" parameters serves. (I know that the Accept header allows for multiple values, i.e. a compound value. So should "httpAccept" also allow for compound values or should it be repeatable?)

       Is there a case to be made for all SRU parameters (bar extension parameters) to be non-repeatable?

       A counterpoint though might be that the values for some parameters could become cumbersome.

    2. This proposal from Ralph was made to avoid the restrictions on index names that the delimiters I originally suggested would put in place. However, we still have similar restrictions on the "sortKeys" parameter which I would suggest is a more widely used parameter than "facetLimit". So we already have restrictions on index names which should be acknowledged somewhere.

    3. The repeated "=" could be problematic for certain parsers.

Sorry if this creates more issues but I guess generally we are looking for simplifications and ease of use.

Tony




-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Mon 12/6/2010 4:30 PM
To: Hammond, Tony; 'OASIS SWS TC'
Subject: Facet limit

Note I changed the subject line.



Tony -  what about ralph's suggestion.  



facetLimit=dc.subject=10& facetLimit=dc.title=100



i.e.  parameter is repeatable and one value per instance. 



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



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