The proposal to create and publish an RSS Autodiscovery specification has passed the RSS Advisory Board with members Matthew Bookspan, Rogers Cadenhead, Jason Douglas, James Holderness, Eric Lunt, Randy Charles Morin and Jake Savin voting in favor and no one voting in opposition.
Both Microsoft Internet Explorer 7 and Mozilla Firefox 2.0 support autodiscovery, an effective way for publishers to let readers know that their sites offer a syndicated feed.
If you're using one of these browsers or another that supports autodiscovery, you might have noticed an orange icon on the right edge of the address bar when you load some pages.
This icon, the common feed icon, indicates that the site offers a syndicated feed. You can click it to subscribe to the feed in the browser's feed reader or another reader such as Bloglines, NewsGator Online or Google Reader. The board's web site uses autodiscovery to publicize our RSS 2.0 feed.
Comments and corrections regarding the new specification can be made on the board's RSS-Public mailing list.
Note: An earlier version of the same proposal passed on Nov. 27 with Bookspan, Cadenhead, Douglas, Holderness, Lunt, Morin, Paul Querna and Savin voting in favor and no one voting in opposition.
I fail to see how that RSS Autodiscovery document can pass as a specification, it's written like a tutorial. There are zero user agent conformance requirements given in it, which makes it absolutely impossible to implement and test. Besides, autodiscovery is not just for RSS, it's for Atom and any other future syndication format too. Thus, any autodiscovery spec must take this into account.
Like the Atom Autodiscovery draft, this spec serves no purpose. Autodiscovery is being defined in the HTML5 spec where it belongs, with both the alternate and feed relationships.
We'll take Atom into account when its autodiscovery specification has been adopted. In the meantime I'm contributing some suggestions towards making the Atom and RSS autodiscovery specs compatible.
As for HTML 5, we felt there was a need to document autodiscovery as it works today in syndication. If it becomes a part of HTML 5, we can address that.
What's an example of a user agent conformance requirement you believe the spec is missing? I'm not clear on what you're expecting.
Firstly, the spec doesn't define or normatively reference any parsing requriements for HTML or XHTML. For XHTML, it can just normatively reference the XHTML 1.0 and XML 1.0 specs. But for HTML, it's not quite that easy. As far as parsing is concerned, HTML 4.01 is cannot be implemented in the real world. No UA uses SGML parsing, as it's defined, and none ever will. The other alternative is to reference HTML5, but it's unfortunately not yet stable. But beyond that, it doesn't define what UAs must do if they encounter the link element in the body.
In XHTML, Firefox, Opera and Safari all recognise the link regardless of where it is placed.
In HTML, Firefox, Opera and Safari all do what the HTML5 spec defines and move the link to the head, regardless of where it occurred in the body (that's why the spec defined it that way). Thus, for them, the autodiscovery link is recognised. However, IE7 does not usually move links to the head. So, except for a few edge cases thanks to IE's buggy parsing, IE7 will not recognise the autodiscovery links occuring in the body.
Consider this test case:
<head>
<title>Autodiscovery</title>
<script type="text/javascript">
document.write("test");
</script>
<link rel="alternate" type="application/atom+xml" href="<a href="lachy.id.au"">lachy.id.au</a> />
</head>
Is that link considered to be in the head or the body? With script disabled, it clearly is, but with script enabled, when "test" is written to the stream, it implies the begining of the body, so it isn't. As a result, whether or not IE7 recognises it is dependent upon whether or not script is enabled, which is clearly insane behaviour.
A head may include more than one autodiscovery link, but each must identify a different feed.
What must a UA do if 2 or more links reference the same feed? How does a UA determine if they do? i.e. Do they need to fully resolve the URIs before comparing if they point to the same place? What if they resolve to different URIs, but one ends up getting redirected to other from the server?
publishers should include only one autodiscovery link per page, using it to identify a site's main feed.
Is that a document conformance requirement? I don't think so, it sounds like more of an informantive note that does not reflect reality. Sites often include more than one syndication feed and there is no reason for the spec to recommend otherwise.
If you decide to include more than one autodiscovery link, the first link should be the site's main feed.
What does that mean exactly? What is a sites main feed? How does one determine that? Is that a testable conformance requirement, or just another informative note? If it's a requirement, how can it be tested? If it's just a note, it should clearly marked as such.
Because attribute names must be lowercase in XHTML, autodiscovery link attributes should have lowercase names in HTML as well.
What is the purpose of that requirement? Presumably a document is still conforming if it uses uppercase, since it doesn't say MUST. Are UAs only required to recognise lowercase for HTML? I don't think that's a good idea. This one is related to the parsing requirements I mentioned above.
This can be a relative URL in pages that include a base element in the header.
Why does a document require the base element in order to use a relative URI? The spec should follow the normal rules for resolving URIs, instead of requring the almost useless and often harmful base element.
Because some software might not check for a base URL in relation to autodiscovery links, publishers should identify feeds with full URLs. When an autodiscovery link is relative and no base URL has been provided, clients should treat the web page's URL as the base.
That is just silly. Instead of requiring authors to fix their behavior based on broken UAs, the spec needs to provide testable conformance requirements that define how all UAs must behave. With a statement like that, you're effectively saying that a UA is conforming even if it doesn't bother to do its job properly!
Although for purposes other than autodiscovery this attribute may contain multiple keywords separated by spaces, in an autodiscovery link, the value must not contain keywords other than "alternate".
Why not? Again, why must authors modify their authoring habbits to suit a few broken UAs. The spec must explicitily define how a UA must behave when it enconters multiple relationships in a link. At present, some browsers don't have a problem with mutliple relationships, others do. That's an interoperability issue that needs to be resolved, not worked around by authors.
Additionally, though rel keywords are case-insensitive elsewhere, "alternate" must be lowercase.
Again, why? What must a UA do if it's not all lowercase? My tests showed that UAs don't have a problem with uppercase, though there may be some the do. Again, that's an interoperibility issue that needs to be resolved, not worked around by authors.
What if 2 or more links pointing to different feeds share the same title? Are there any special handling requriements for UAs? Is it a document conformance requriement that they titles be different?
Although type values are case-insensitive for other HTML and XHTML links, the value must be lowercase for autodiscovery.
Why? What must a UA do if it's not lowercase? My tests showed that they don't have a problem with it. But if some do, then this is another interoperability issue.
Your comment form messed up the markup in that comment. Can you edit it to remove all those unnecessary line breaks for me.
Sorry about that. I'll see if I can restore the comment to the desired formatting.
Urdu Qaida - Discover our collection of Urdu Qaida, offering clear guidance for learning Quranic Arabic. Our Urdu translations make it easier for learners to grasp the essentials of Quranic recitation, ensuring a solid foundation for your spiritual journey.
