On Wed, Oct 8, 2008 at 12:13 PM, BrandonLive <bran...@brandonlive.com>wrote:
> 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:
> ::existing attributes::
> rel - Defines the relationship between the OSD file and the Url
> described in this element.
+1 I'm generally in favor of this, insofar as the 'rel' attribute feels
like the right way to express what we want. But there are a few caveats
I'll get to below.
+1 It is subjective of course, but "results" feels like the right word for
it to me.
> Requirements: This attribute is optional but recommended.
-1 No need to make it recommended. The default matches the user's
expectations. Instead, how about:
Requirements: This attribute is optional.
> 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.
-1 I'd rather we didn't specify ordering here. I know that some clients
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.
> 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"/>)
-1 The 'type' attribute expresses this already in a way that is consistent
with similar elements in HTML and Atom. How is 'format' better?
Other possible "rel" values to document would be:
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.)
"preview" - a preview of the search results in a low-resolution format
> (see the thread on IE8's usage).
Can you take a stab at documenting this?
Thanks for the spec proposal, Brandon! This is exactly what I think we need
to make progress.