The following RSS Advisory Board proposal has been made by Rogers Cadenhead and seconded by Randy Charles Morin.
Under the advisory board charter, the board has seven days to discuss the proposal followed by seven days to vote on it. Interested parties can comment on the proposal on the mailing list RSS-Public.
Proposal
For the last 18 months, the RSS Advisory Board has been drafting a set of best-practice recommendations for RSS. Working with the developers of browsers such as Microsoft Internet Explorer and Mozilla Firefox, aggregators such as Bloglines and Google Reader, and blogging tools including Movable Type, we've looked for areas where questions about the RSS format have led to differences in how software has been implemented to produce and consume RSS feeds.
The result of our work is the RSS Profile. The lead authors are James Holderness, Morin, Geoffrey Sneddon and myself. The profile isn't a set of rules; it's a set of suggestions drafted by programmers and web publishers who've been working with RSS since the format's first release in 1999. Our goal is for the profile to be the second document programmers consult when they're learning how to implement RSS.
The profile tackles some long-standing issues in RSS implementation, including the proper number of enclosures per item, the meaning of the TTL element and the use of HTML markup in character data.
In addition to recommendations for the RSS elements documented in the specification, the profile includes advice for four common namespace elements: atom:link, content:encoded, dc:creator and slash:comments.
We propose that the board endorse and publish the RSS Profile, making it available under a Creative Commons Attribution-ShareAlike 2.0 license so that others can build upon and extend it with their own recommendations.
Additionally, we propose that the following sentence be added to the About this document section of the specification, as a new fifth paragraph: "The RSS Profile contains a set of recommendations for how to create RSS documents that work best in the wide and diverse audience of client software that supports the format."
The proposal to revise the RSS specification has passed 5-1 with RSS Advisory Board members Matthew Bookspan, Rogers Cadenhead, Christopher Finke, Randy Charles Morin and Paul Querna voting in favor, Eric Lunt voting against and members James Holderness, Meg Hourihan, Jenny Levine and Jason Shellen abstaining.
The Extending RSS section of the specification has been clarified with the addition of the words "and attributes" twice in the following sentence:
A RSS feed may contain elements and attributes not described on this page, only if those elements and attributes are defined in a namespace.
No other changes were made. All edits to the specification are logged. This revision of the document has the version number 2.0.9.
In RSS Profile research, I analyzed how frequently RSS core elements and namespace elements appear in feeds.
Here's the compiled stats for item elements. Part one covered channel element usage.
The full report reveals that the most popular namespace element in RSS items is dc:creator from the Dublin Core namespace, which appeared in 42.7 percent of the feeds.
The second-most common is wfw:commentRss from the Well-Formed Web namespace, appearing in 34.3 percent. (This total includes wfw:commentRSS, a common miscapitalization of the element name.)
All core elements were found in at least 5 percent of the feeds surveyed with the exception of source, which appeared in 3.0 percent.
Read More
As part of the research for the RSS Profile, I compiled statistics on how frequently RSS core elements and namespace elements appear in feeds.
The full report reveals that the most popular namespace element is dc:language from the Dublin Core namespace, which appeared in 36 percent of the feeds.
The second-most common namespace element is atom:link from the Atom syndication format, appearing in 15 percent.
Four core elements were found in fewer than 1 percent of the feeds surveyed: textInput (0.31 percent), rating (0.26), skipDays (0.10) and the skipDays element day (also 0.10).
Read More
The following RSS Advisory Board proposal has been made by Randy Charles Morin and seconded by Rogers Cadenhead.
Under the advisory board charter, the board has seven days to discuss the proposal followed by seven days to vote on it. Interested parties can comment on the proposal on the mailing list RSS-Public.
Proposal
We'd like to propose a small clarification to the RSS 2.0 specification to remove uncertainty in the community over whether extension attributes are allowed to core RSS elements.
In the section Extending RSS, we propose that the following sentence be changed:
A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.
It should be revised to read as follows:
A RSS feed may contain elements and attributes not described on this page, only if those elements and attributes are defined in a namespace.
Rationale
When namespaces were added to RSS 2.0 by Dave Winer in 2002, he wrote on his weblog that he was deferring the details of their implementation to the Namespaces in XML specification:
I've added the section explaining how to extend RSS through namespaces. I'm basically telling you to ask the W3C how namespaces work, and do it the way they tell you to do it. I don't want to assume the problem of documenting namespaces in the RSS spec.
When namespace support was added, that version of the specification linked to a new RSS 2.0 sample file that used them. This sample file was part of the specification for the next two years.
The first line in the sample file makes use of a namespace attribute:
<rss version="2.0"
xmlns:blogChannel="http://backend.userland.com/blogChannelModule">
In the above, xmlns:blogChannel is a namespace attribute contained by the rss element that declares the blogChannel namespace.
The proposed spec revision makes it clear that this is valid RSS. If namespace attributes aren't valid RSS, every RSS feed that declares a namespace in the rss element is invalid.
Some namespace developers, most notably Microsoft, have employed namespace attributes on core elements.
To clear up confusion, support implementers who've emulated the specification, and give more clear guidance to namespace creators, this is an important and necessary clarification.
