Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
OpenSearch
Home
+ new post
About this group
Join this group
Message from discussion Draft 4 Proposal: "rel" attribute for <Url>
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
BrandonLive  
View profile  
 More options Oct 8 2008, 4:36 pm
From: BrandonLive <bran...@brandonlive.com>
Date: Wed, 8 Oct 2008 13:36:10 -0700 (PDT)
Local: Wed, Oct 8 2008 4:36 pm
Subject: Re: Draft 4 Proposal: "rel" attribute for <Url>
Print | View thread | Show original | Report this message | Find messages by this author
Thanks Dewitt.

Some inline responses:

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

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google