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.

> -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.

> > 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 :)