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: httpAccept repeatable or non-repeatable


Title: RE: Facet limit

Tony - I am sure that nobody intended httpAccept to be repeatable. I will fix this in the draft I am working on.

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




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