As per the other thread, it sounds like creating individual threads is
the way to go in order to discuss and document changes for Draft 4.
The addition to the <Url> Element section would consist of:
Attributes:
::existing attributes::
rel - Defines the relationship between the OSD file and the Url
described in this element.
Default: "results".
Requirements: This attribute is optional but recommended.
If a rel
value other than "results" is specified for a given format, it should
appear after the "results" <Url> element for compatibility with
existing clients.
This attribute removes the need to hack "suggestions" and other things
into the "format" attribute, and would allow search suggestions to be
provided in a variety of formats (ie <Url format="application/rss+xml"
rel="suggestions" template="foobar"/>)
Other possible "rel" values to document would be:
"preview" - a preview of the search results in a low-resolution format
(see the thread on IE8's usage).
> -1 I'd rather we didn't specify ordering here. I know that some clientsI'm also fine with that, but my concern would be for a new implementer
> today only look at the first Url, but hinting that non-"results" Urls should
> appear later in XML-ordering doesn't avoid the need for the clients to use
> heuristics to pick among different search types.
who wants to target IE8 and puts a "preview" URL ahead of their
"results" URL will undoubtedly hit unexpected behavior with clients
like IE7, who will try to use the "preview" URL for the search query.
> -1 The 'type' attribute expresses this already in a way that is consistentSorry, when I said "format" I meant "type" - I think we agree here. I
> with similar elements in HTML and Atom. How is 'format' better?
was just explaining that something like the existing "application/x-
suggestions+json" type is wrong, and that it should have the normal
JSON mime identifier as its "type" and use "rel" to define it usage.
The current "application/x-suggestions+json" type value in the
Suggestions spec uses the "type" attribute to define both the format
and the intended usage, whereas I think we both agree these should be
seperate.
Agreed. But... I have a project where the "itemlist" example has
> And here's the meat of my reservation. I don't want to add complexity just
> because of neat ideas. If we can document the rel values clearly and show
> some live examples in the real world (like we have with "results" and
> "suggestions") then lets go for it, otherwise let's pass on adding them
> now. (I made a mistake by allowing too many speculative values that no one
> uses for the 'role' attribute on the Query.element.)
already been implemented :)
It would be fairly simple to implement in Firefox (our search service
is implemented in JavaScript), and could likely land for Firefox 3.1.
If anyone's interested in doing the work I can provide guidance and
help get it landed - a good first step would be to file a bug about it
at https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Search
and CC me.
Gavin