Need feedback on a "Arbitrary parameter" extension

[Erik Mogensen]

Given an Atom response with some <opensearch:Query role="subset"> elements, a powerful extension would be the ability for the server to tell the client some additional values of additional query parameters.

Let's say we have a simple OpenSearch description document, with

  <Url template="/search?q={searchTerms}&from={dt:start}&to={dt:end}&params={param:something}"/>

The client fills out this (perhaps by way of drilling down from previous search responses) to a response which contains a date restricted response (e.g. from 2013-01-01 through 2013-12-31):

<Query role="request" searchTerms="xyzzy" dt:start="2013-01-01T00:00:00Z" dt:end="2014-01-01T00:00:00Z"/>

Now the datetime restriction doesn't say anything about *what* the server is actually filtering on; is it the date at which the document was created? Indexed? last modified? state change? Any? The {param:something} parameter could be used by the server to change something about the response:

<Query role="related" searchTerms="xyzzy" dt:start="2013-01-01T00:00:00Z" dt:end="2014-01-01T00:00:00Z" param:something="date-edited" title="Edited date"/>

<Query role="related" searchTerms="xyzzy" dt:start="2013-01-01T00:00:00Z" dt:end="2014-01-01T00:00:00Z" param:something="date-create" title="Creation date"/>

<Query role="related" searchTerms="xyzzy" dt:start="2013-01-01T00:00:00Z" dt:end="2014-01-01T00:00:00Z" param:something="date-publish" title="Publish date"/>

<Query role="related" searchTerms="xyzzy" dt:start="2013-01-01T00:00:00Z" dt:end="2014-01-01T00:00:00Z" param:something="date-any" title="Any date"/>

The client could then provide four UI elements which would add (say) &params=date-edited to the request, as per the OpenSearch spec, and the server might understand that request as being a date restriction specifically for the edited date.

Another way this could be used (let's say we have an OpenSearch document with the Semantic extension):

<Query role="subset" searchTerms="xyzzy" semantic:related="urn:concept1 urn:concept2" param:something="related-intersection" title="All concepts"/>

<Query role="superset" searchTerms="xyzzy" semantic:related="urn:concept1 urn:concept2" param:something="related-union" title="Any concept"/>

Here, the first Query is effectively a link to the subset of documents where urn:concept1 and urn:concept2 *intersect* (i.e. an AND search).  The second Query element indicates that the server should respond with the union of the documents that match urn:concept1 and urn:concept2.

In both cases, the client does not need to (and should not) know the meaning of the param:something values, they are just echoed back to the server when the user selects the appropriate Query element.

Both of these ways this proposed extension are used could easily warrant their own extension; however I feel that very specific extensions are less useable than generic ones like this.

Just to make a point, here's a third way it could be used (irrespective of any OpenSearch extensions):

<Query role="related" searchTerms="xyzzy" param:something="order-relevance" title="Order by Relevance"/>

<Query role="related" searchTerms="xyzzy" param:something="order-title" title="Order by Relevance"/>

<Query role="related" searchTerms="xyzzy" param:something="order-freshness" title="Newest first"/>

Here, the server might change the order of the results based on the value of the param:something parameter; but the client wouldn't necessarily need to know.

The big question is if these things belong in a generic extension, of if more small one-off extensions should be built so that UIs can react more appropriately when it comes to these types of thing.

-- 

-mogsie-