OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws-comment message

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

Subject: Proposal for a revised syntax for "facetLimit"

Title: Proposal for a revised syntax for "facetLimit"

I'd like to propose a revised syntax for the "facetLimit" parameter.

On a global basis (across all indexes) this parameter looks like this:


On a per-index basis it looks like this:


This is the syntax currently defined in the SRU 2.0 Draft.

I am thinking that this is problematic - because the parameter name ("facetLimit") is now namespaced with the index name - and in effect produces a new parameter name - one wholly unrelated to the original parameter name. It makes it exceedingly difficult to recognize and deal with this parameter.

So, I am wondering if an alternate syntax, e.g. something like

    facetLimit = dc.creator:5,dc.subject:10

would be more acceptable. The parameter name is single and uncorrupted, and only the value is compound.

This seems to me to be much more straightforward and is readily tractable. As regards a global facet limit we might consider introducing a new parameter "defaultFacetLimit", e.g.


I'm also wondering in the above if the comma separator (",") is valid as it might be a legal name character. That is, the only doubt I have is that both the "prefix" and the "name" parts of the index name are "simple-string" productions (as per the BNF) and basically allow for any sequence of non-whitespace chars not including one of these:


Maybe that would mean that an alternate syntax such as the following would be preferred:

    facetLimit = "dc.creator=5 dc.subject=10"

Here I have now added quotes as required because of the whitespace chars (or could be "/" chars instead of "=" chars).

I should say that the first syntax proposed would be easiest to work with. A comma-based delimiter would also be consistent with the "sortKeys" parameter. It does, however, have the demerit of limiting the index names that could be used with this syntax, i.e. it would exclude names or prefixes containing ":" or ",". Is that likely to be a problem?

(I would note in passing that this permissive approach to naming does have some downsides - as here in finding suitable delimiters.)

Are there any comments re this proposal? Would we be able to go for the simpler syntax (with ":' and ",") or do we need to be strict and consider something like the alternate syntax (with "=" and " ")?



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]