[Opensearch-discuss] Using “rel” to identify the relationship of a <Url /> to its source.

[Steve Ickman]

Hi all,

I sent DeWitt e-mail the other day asking for clarification about <Url /> processing instructions missing from the 1.1 (draft 3) spec and during the course of our mail exchange I also asked why the Suggestions extension works the way it does.  I proposed an alternate way of approaching the problem which DeWitt suggested I submit to the alias for feedback.

The Suggestion extension says that a <Url /> “type” attribute of “application/x-suggestions+json” indicates the response returned for a query will contain suggestions.  Response type is certainly one way to approach the problem.  But what if my client doesn’t want to process JSON?  We could add an additional type of “application/x-suggestions+xml” which works and just means we have to define an additional results format.  But what if I want to return suggestions using a more generic type of “application/x-list+xml” or “application/x-list+json” and this results format is used not only for returning suggestions but the users query history as well.  Seems desirable but problematic given the way the extension currently works.

Another way to approach this problem would be to adopt the Atoms “rel” attribute found on <link /> entries.  Using “rel” a source might describe the following set of <Url /> entries:

     <Url type=”application/atom+xml” rel=”results” template="http://exmaple.com/query?q={searchTerms}&fmt=atom" />
     <Url type=”application/rss+xml” rel=”results” template="http://exmaple.com/query?q={searchTerms}&fmt=rss" />
     <Url type=”application/x-list+xml” rel=”suggestions” template="http://exmaple.com/suggest?q={searchTerms}&fmt=xml" />
     <Url type=”application/x-list+json” rel=”suggestions” template="http://exmaple.com/suggest?q={searchTerms}&fmt=json" />
     <Url type=”application/x-list+xml” rel=”history” template="http://exmaple.com/history?u={example:user}&fmt=xml" />
     <Url type=”application/x-list+json” rel=”history” template="http://exmaple.com/history?u={example:user}&fmt=json" />

As you can see, the source above is very flexible and has several overlapping result types.  The use of "rel" removes the ambiguity that duplicated result types would currently cause.  It also allows for growth as extensions can add support for new "rel" types that existing clients would simply ignore.  With regards to how this impacts existing OSD files, the default relationship would be assumed to be "results" (unless type is "application/x-suggestions+json" then "suggestions") which means all existing OSD files would work fine.

Thoughts?