From: Hammond, Tony
[mailto:t.hammond@nature.com]
Sent: Wednesday, November 10, 2010 4:09 AM
To: search-ws@lists.oasis-open.org
Subject: [search-ws] Proposal for a revised syntax for
"facetLimit"
Hi:
I'd like to propose a revised syntax for the "facetLimit" parameter.
On a global basis (across all indexes) this parameter looks like this:
facetLimit=10
On a per-index basis it looks like this:
facetLimit:dc.creator=5
facetLimit:dc.subject=10
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.
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).
I should say that the first syntax proposed would be easiest to work with.
[[As regards the liberal attitude to name chars, this allow anything approach
is a dangerous path to tread. We trod a similar path with DOI syntax and that
caused many problems - not least the '#' char which occurs in DOIs based on
SICI codes, with '#' being a SICI mod-37 check char, and the havoc that wreaked
when DOI was embedded in a URL. Less is decidedly more.]]
I would like to get an early opinion on this as we are (as ever) in the middle
of development. Basically we have two choices: to preempt the WG's decision and
go with an interpretation of "facetLimit", or to go with a custom
parameter which sits outside the SRU syntax. We obviously would much prefer to
stay onside.
Do I need to put this to the SRU list, or is this something that we could maybe
decide on ourselves and include in the public draft?
Cheers,
Tony
********************************************************************************
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
********************************************************************************