A Busy Developer’s Guide to RSS 2.0

Disclaimer: This is not spec text.

Okay, so you’re busy and you’d like to get a quick implementation of RSS up asap and have it work with the largest number of feed readers and aggregators. Coool. Here are some tips for that will make your work go more smoothly, based on the experience of real developers.

1. Find a feed that’s popular and do what it does. This is the best advice you can get, for any format any time. If you do exactly what the New York Times does, or what Yahoo does, or what my feed does (it was the first) then you can’t go too far wrong, because all the feed readers will have had to deal with whatever these feeds do, because they are so popular, and old.

2. If you’re doing a podcast feed, at most one enclosure per item. There’s been some controversy about whether or not you can have more than one, and the spec doesn’t specifically disallow it, but if you want maximum interop, you shouldn’t have more than one enclosure per item.

3. No relative URLs. In your descriptions, and in links, all addresses should be absolute. Most readers and aggregators won’t do anything special with relative URLs, so your links will be broken in those tools if you use relative links.

4. Don’t include markup in any elements other than descriptions, at the channel level and at the item level. Where you include markup, you should encode ampersands and less-thans in the way proscribed recommended for HTML by the W3C.

5. Avoid using elements in namespaces when there are already core elements that do the same thing.

6. Use namespaces that are already in use by others before inventing new ones.

Notes

1. Thanks to Tim Bray for providing a great checklist to work from. 🙂

2. If this actually gets used by a lot of people, perhaps we should have a way for a feed to notify a reader that it is following these guidelines.

3. This is an informal document, and always will be, and it’s still very much a draft and a request for ideas. It is not spec text. If you think something belongs in this profile, post a comment, let’s consider it.

4. If have strongly differing ideas, please by all means, post your own BDG.

5. Some people will say I’m stupid, or corrupt, or incorrigible, even toxic, or any number of negative personal things. What they’re really saying is they don’t like me. That’s okay, no one is liked by everyone. It doesn’t hurt my feelings, and you shouldn’t worry about it, because I don’t.

6. Namaste y’all!

27 responses to this post.

  1. […] Here are a few simple ideas I call A Busy Developer’s Guide to RSS 2.0. Comments and suggestions are welcome.  […]

    Reply

  2. Works for me.

    Reply

  3. Posted by Lou on March 8, 2006 at 8:48 am

    For someone generating RSS, how is this easier than a clarification of the spec? And for someone aggregating/displaying RSS, how does this help?

    Not trying to be rude, just trying to see the rationale.

    Reply

  4. Lou, the spec is frozen. Nobody can change it, not even me, the author.

    Anyway, that’s about all I want to say about that. It’s all been covered ad nauseum, over and over. Let’s move forward. Thanks.

    Reply

  5. This is great! An alternative title:

    “A Really Simple Guide to Really Simple Syndication”

    After reading this I feel I know where to start and where the common pitfalls are. Care to add list of links called “Resources” and include a link to spec text or other BPD’s?

    Steve

    Reply

  6. “proscribed” -> “prescribed”

    Reply

  7. […] Dave Winer: Okay, so you’re busy and you’d like to get a quick implementation of RSS up asap and have it work with the largest number of feed readers and aggregators. Coool. Here are some tips for that will make your work go more smoothly, based on the experience of real developers. […]

    Reply

  8. Looks good to me. In fact, my work would be easier if more feed producers followed these simple tips 🙂 FWIW, I have a small set of other RSS tips at http://www.bradsoft.com/support/faq/faqitem.asp?id=86

    Reply

  9. Thanks! This was very helpful. btw – copying a feed that works is what I would have done anyway. But the other parts about absolute links and where to include markup is very helpful.

    Reply

  10. Posted by Marcelo Lopez on March 8, 2006 at 11:35 am

    Namaste ! Sounds like we have a LOST fan in our midst ? Could it be ? Or just someone wishing everyone a nice existence ? Either way, it’s good.

    Reply

  11. Dave: looks good. Might I suggest also including a link to validation resources?

    Reply

  12. Any advice on categories? Documentation is slim in that area and we would like to use the categories to display different news items on different areas of our site, both location and topic oriented.

    Reply

  13. Posted by dennis on March 8, 2006 at 3:55 pm

    This looks like great advice and a good place to put more advice, I have just one nitpick: isn’t Note 2 kinda hard for readers to do anything with, given Note 3?

    Reply

  14. Jeremy, not sure what to say about categories, other than (please) use them.

    I’ve heard it said that documentation is slim, but what more do you need to know?

    Reply

  15. […] Dave Winer auspiciously posted his busy developer’s guide to RSS… amazing! on the. very. day. when I set out to tackle these feeds (er, does that make me a developer? hmmm) and there was a comment by Brad pointing to his advice about feeds (including guids, hence crossed-off item). […]

    Reply

  16. […] Dave’s WordPress Blog » A Busy Developer’s Guide to RSS 2.0 (tags: rss) […]

    Reply

  17. For example yahoo has media categories and lists them as:
    ycantpark
    mobile

    Microsoft has category and lists it as:
    Visual Studio .NET
    .NET development

    So if I have a news item with a location category of Seattle, a subject of construction and an impact of lane closures does it look like this:
    Seattle
    construction
    Seattle

    Seattle

    Is there a standard or a recommendation so that if we do something now it will work for readers and our own uses? The specification leaves category wide open, with the exception of domain which doesn’t necassarily apply for us.

    If it were just xml we would be less likely to have concern about it but since our primary audience is folks with a wide variety of readers is there a recommendation to follow? Appreciate your thoughts about this.

    Reply

  18. took the xml structure out of my last response…. darn

    Reply

  19. Ack! That wasn’t supposed to happen. I’ll try again. Sorry about that.

    Here’s a few things from the RSS 2.0 spec that have never been entirely clear to me. It’s be great if you could shed some light on them. I’m afraid your guide above doesn’t really clarify them either, so a response would be excellent. Some of these might seem a little dumb, but bear with me.

    By 4, do you mean that *all* elements that contain text (including <title/>, <description/>, <author/>, <copyright/>, <category/>, &c.) can contain entity-encoded HTML?

    Also, the difference between <link/> and <guid isPermaLink=”true”/> is somewhat vague. For instance, say you have a seperate weblog and linklog. Which is best to use to indicate a weblog entry permalink, and for the linklog, how exactly should <link/> be treated by an aggregator (assuming it contains the link discussed in the linklog entry) as opposed to <guid isPermaLink=”true”/>, which points to the linklog entry itself?

    And then there’s a couple of other things about aggregator behaviour that have been bugging me for years now. Assuming you have a weblog that stored both the timestamp of each entry’s last edit and the date/time of each entry’s creation, how should you indicate in the feed that some entry or entries have been updated since their creation? I’m assuming that the correct behaviour is that the feed should contain the most recent edits rather than the most recent items and that when fetching a feed, an aggregator should do a conditional GET on the feed so that if the feed is fried rather than baked, the code generating it will only supply the items updated since the supplied date/time.

    Similarly, if a (plain) <guid/> uniquely identifies an item, is it correct or incorrect that if the contents of an entry’s <link/> (functionally the item’s permalink in this case) changes, the items should be treated as different? And if there’s no <guid/> element attached to an entry, should the contents of <link/> be treated as a substitute for a <guid/>?

    One last thing: if, for some bizarre reason (say, there was a power-outage that caused the server’s clock to reset shortly before post was written, and the entry is later updated to fix this), an entry’s <pubDate/> changes between fetches, how should that entry be treated? Same entry or different? And which date should take precedence?

    Reply

  20. […] Yesterday I wrote, in my BDG to RSS 2.0, “Some people will say I’m stupid, or corrupt, or incorrigible, even toxic, or any number of negative personal things. What they’re really saying is they don’t like me. That’s okay, no one is liked by everyone. It doesn’t hurt my feelings, and you shouldn’t worry about it, because I don’t.” There’s more to say about that. When someone says that kind of personal stuff, you can turn it back and ask them why they are making it so personal, and how do they know so much about Dave. My bet they don’t know me at all and they have a reason to want you not to listen to me. I won’t show you that kind of disrespect, I want you to get all the opinions you feel you need, and then make the right choice, for you. You should never base your opinion of some idea on what someone else thinks of the person who is advocating the idea. That is a perfect example of disrespect, of you. Posted by Dave Winer Filed in Uncategorized […]

    Reply

  21. Why relative / absolute URLs? Most programming languages’ APIs make it trivial to interpret URLs in their correct context. For example, in Java, you write something like:

    URL u = new URL(link, context);

    Then again, it makes sense given the stupidity of some RSS readers…

    Reply

  22. Namaste y’all! Ha! We must be on the same wavelength. That’s how I signoff my email newsletter.

    Reply

  23. Based on this input, and on Susan Kitchen’s input (the 2020 Hindsight link above), I have committed and deployed a change to the Feed Validator to issues warnings if elements like content:encoded is encountered in items.

    These are only warnings — the feed is still valid. The extended help on the warning links to these discussions, and provides a concrete suggestion on how to produce an interoperable RSS 2.0 description element.

    If somehow I have misread your intent, or if there are additional elements that should be so flagged, simply let me know and I will adjust, revert, and/or add more checks.

    Reply

  24. Sam, you should do what you want, I’ve never felt I had any say in what your web app does, and I don’t expect to now, and I’ve never recommended that anyone use it. I do hope you observe the disclaimer at the top of the page. That’s there to keep people from thinking that this is any way an official document. These are just some ideas that I have that I wanted to share.

    Reply

  25. […] March 8, 2006. Dave Winer announces his Busy Developer’s Guide to RSS. […]

    Reply

  26. […] Google is “pleased to announce an alpha release of RSS feeds on Google Video.” They announced it on a Yahoo mail list, where a Yahoo extension to RSS is discussed. How’s that for cooperation. Nice work. No sarcasm. It’s even better because this is exactly where Apple could have worked with others in the industry, instead of blazing their own trail. One of the guidelines in my Busy Developers Gude is: “Avoid using elements in namespaces when there are already core elements that do the same thing.” I’ve added a #6 to the list. “Use namespaces that are already in use by others before inventing new ones.”  […]

    Reply

Leave a reply to Lou Cancel reply