[Opensearch-discuss] Using "rel" to identify the relationship of a <Url /> to its source.
bhpaddock at msn.com
Tue Mar 27 11:47:33 PDT 2007
I would jump on here and say "do it!" - but I work with Steve and helped
bounce around ways to separate what's getting returned and how it's getting
returned, so I'm a little biased J Would love to see it make 1.1 though,
especially since it seems to leave things much more open for extensions
along the lines of the Suggestions one in a cleaner, more future-proof way.
From: opensearch-discuss-bounces at lists.opensearch.org
[mailto:opensearch-discuss-bounces at lists.opensearch.org] On Behalf Of DeWitt
Sent: Tuesday, March 27, 2007 7:45 AM
To: Steve Ickman
Cc: opensearch-discuss at lists.opensearch.org
Subject: Re: [Opensearch-discuss] Using "rel" to identify the relationship
of a <Url /> to its source.
As Steve mentioned, we discussed this off-list and I like the proposal. It
has come up before, but never in the context of such a valuable and
real-world use case. I am in favor of including it now that it is clear how
and why clients and servers would want the rel attribute, and how they don't
have a reasonable alternative in the existing spec.
The question remains whether or not this should be done in an extension to
the current spec, postponed until a future version, or incorporated into
My preference, due to how this change degrades gracefully for clients that
don't recognize the new attribute, is that this is a reasonable thing to add
to OpenSearch 1.1 before it is marked as final.
And since we're on the topic, I'll send around an email shortly regarding my
thoughts on a "last call" for OpenSearch 1.1.
On 3/26/07, Steve Ickman <stevenic at microsoft.com > wrote:
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=%7BsearchTerms%7D&fmt=atom> &fmt=atom" />
<Url type="application/rss+xml" rel="results" template="
<http://exmaple.com/query?q=%7BsearchTerms%7D&fmt=rss> &fmt=rss" />
<Url type="application/x-list+xml" rel="suggestions" template="
<http://exmaple.com/suggest?q=%7BsearchTerms%7D&fmt=xml> &fmt=xml " />
<Url type="application/x-list+json" rel="suggestions" template="
<http://exmaple.com/suggest?q=%7BsearchTerms%7D&fmt=json> &fmt=json " />
<Url type="application/x-list+xml" rel="history" template="
<http://exmaple.com/history?u=%7Bexample:user%7D&fmt=xml> &fmt=xml" />
<Url type="application/x-list+json" rel="history" template="
<http://exmaple.com/history?u=%7Bexample:user%7D&fmt=json> &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.
opensearch-discuss mailing list
opensearch-discuss at lists.opensearch.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opensearch-discuss