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).
"itemlist" - a complete list of all items within the scope of this
search location
"recent" - a list of items recently added to this scope
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.
Thanks!
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.
+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.
Default: "results".
+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.
> > Requirements: This attribute is optional but recommended.
> -1 No need to make it recommended. The default matches the user's
> expectations. Instead, how about:
That's fine with me.
> -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.
I'm also fine with that, but my concern would be for a new implementer
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 consistent
> with similar elements in HTML and Atom. How is 'format' better?
Sorry, when I said "format" I meant "type" - I think we agree here. I
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.
> 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.)
Agreed. But... I have a project where the "itemlist" example has
already been implemented :)
I would love to have this be a part of the common spec instead of a
custom extension as I think it is generally useful to other consumers.
On Wed, Oct 8, 2008 at 1:36 PM, BrandonLive <bran...@brandonlive.com> wrote:
> > -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.
> I'm also fine with that, but my concern would be for a new implementer > 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.
Description document owners will figure it out quickly, I suspect. And we could add a warning to the validator.
> -1 The 'type' attribute expresses this already in a way that is > consistent > > with similar elements in HTML and Atom. How is 'format' better?
> Sorry, when I said "format" I meant "type" - I think we agree here. I > 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.
Ahh, now I understand. Yes, that makes great sense to me.
While the latter would now be discouraged, many clients will no doubt want to support it still. Given that the only place the "application/x-suggestions+json" appears is the Suggestions 1.0 spec (which, incidentally, I just branched to create 1.1), it sounds like we can confine our commentary about backward compatibility there.
If I understand correctly, then objection withdrawn. +1
> > 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.)
> Agreed. But... I have a project where the "itemlist" example has > already been implemented :)
> While the latter would now be discouraged, many clients will no doubt want
> to support it still. Given that the only place the
> "application/x-suggestions+json" appears is the Suggestions 1.0 spec (which,
> incidentally, I just branched to create 1.1), it sounds like we can confine
> our commentary about backward compatibility there.
Sounds good :)
> > Agreed. But... I have a project where the "itemlist" example has
> > already been implemented :)
> Is this something you can share with the group?
Unfortunately, nothing ready to share quite yet. Should have
something to show pretty soon though, and I think you'll like it.
What's the incentive for an author to use the new rel="suggestions" type="application/json" syntax?
All the existing clients -- say some 70% of the market share -- support only the old syntax Future browsers may support rel="suggestions", but even those new browsers will support the old syntax, so why would anyone switch? Even many years from now there will still be a huge percentage of clients that only support the old format, thus publishers have an incentive *not* to adopt the newer format.
Following that logic, I imagine that we'll see a lot of hybrid Urls with the new "rel" attribute *and* the old mime-type:
> > While the latter would now be discouraged, many clients will no doubt > want > > to support it still. Given that the only place the > > "application/x-suggestions+json" appears is the Suggestions 1.0 spec > (which, > > incidentally, I just branched to create 1.1), it sounds like we can > confine > > our commentary about backward compatibility there.
> Sounds good :)
> > > Agreed. But... I have a project where the "itemlist" example has > > > already been implemented :)
> > Is this something you can share with the group?
> Unfortunately, nothing ready to share quite yet. Should have > something to show pretty soon though, and I think you'll like it.
Sorry... I realize this thread is a bit old but...
The incentive to support rel="suggestions" is that clients can now
return suggestions in a format other then JSON. Win7 for instance
doesn't have a JSON parser and I'm sure Brandon doesn't want to have
to implement one if he doesn't have to. Separating the the templates
relationship from its return type means servers can return suggestions
as "application/atom+xml" if the want them to show up in Windows (or
other clients without JSON parsers.)
I don't think Win7 currently supports suggestions so this isn't a huge
deal but I think the argument is valid.
On Thu, Nov 27, 2008 at 9:29 AM, steve <ick...@gmail.com> wrote:
> Sorry... I realize this thread is a bit old but...
> The incentive to support rel="suggestions" is that clients can now
> return suggestions in a format other then JSON. Win7 for instance
> doesn't have a JSON parser and I'm sure Brandon doesn't want to have
> to implement one if he doesn't have to. Separating the the templates
> relationship from its return type means servers can return suggestions
> as "application/atom+xml" if the want them to show up in Windows (or
> other clients without JSON parsers.)
> I don't think Win7 currently supports suggestions so this isn't a huge
> deal but I think the argument is valid.
On Thu, Nov 27, 2008 at 12:57 PM, DeWitt Clinton <dew...@unto.net> wrote: > My point was simply that, because most existing clients aren't aware of it, > how are we going to encourage adoption in new description documents?
It would be fairly simple to implement in Firefox (our search service is implemented in JavaScript), and could likely land for Firefox 3.1.
