Slashdot Mirror

The RSS itself is ok, http://feedvalidator.org/check.cgi?url=http%3A%2F% 2Fnews.google.com%2F%3Fned%3Dus%26topic%3Dh%26outp ut%3Drss but that's not the least of it..

Just take any of the <description> entries and validate them as valid HTML 4.01 and you'll see that google make the same mistakes each and every time with things like a closing </b> crosses an opening <font> and no closing </tr> and </td> before the closing </table>, etc. What perverse and simple errors they have in their main template. How can they overlook this?

...it's great that Slashdot has one, and it's great that you guys started using em dashes a lot (like in the subject of this very article), but &mdash; isn't a valid RDF/RSS or XML character entity. So it shows up literally as "&mdash;" in feed readers.

Use the numerical equivalent (&#8212;) instead, gracefully degrade it to "--", or simply include it as an unescaped multibyte character (yay UTF-8). But do something, it looks dumb.

Nonsense. RSS doesn't have to be governed by a standards body for Apple's actions to be "wrong." The spec can be found at http://blogs.law.harvard.edu/tech/rss quite easily. And there's nothing stopping Apple from visiting http://feedvalidator.org/ to make sure their code works. They clearly didn't bother to do that.

This isn't Apple bashing either. Many of the people who are most upset about this, myself included, are diehard Apple users.

Apple screwed up photocasting, pure and simple. And they screwed up their podcasting spec too by releasing poorly designed specs (and I'm being generous here by calling their first attempt a "spec") and then changing things later. And they've made processing of some of their elements amazingly difficult. For instance, the itunes:keywords element can either be delimitted by commas or spaces. There's nothing in the xml itself to indicate for sure which you're dealing with, you just have to guess. Check if there's a comma present, if so, split by commas, otherwise, split by spaces. But what happens if they meant to use the single keyword "bad apple" instead of "bad", "apple"? There's no way to know for sure. The whole point of a spec is to avoid this kind of rediculous imprecision.

So yeah, Apple doesn't seem to have the first clue about generating valid RSS or XML any of that stuff. And all they had to do was ask. Secrecy is not always your best friend.

The source code for FeedValidator is freely available on SourceForge

Even better: when they're a company that exclusively promotes the use of RSS and they don't even have a valid RSS feed, it seems like a good reason to laugh at them.

blech, versioning quagmire in feed formats. who needs the hassle? just use Atom 1.0 from IETF, no less.

Atom wins hands-down. Things are actually well specified .
I can just walk through the atom specification, implementing it as I go, and not have any questions about what is required, what type of content can be present in any one element, I don't have to look up five even less well-specified different modules just to get the basics of the feed together (and thus also don't have to worry about namespaces), what elements and attributes mean (actually, I spent a minor five minutes agonizing over what I should put in the term atribute of the category element, given that the label attribute contains the human readable version, before realizing that I was completely free in this, as the "scheme" os up to myself, and deciding to mirror how categories are named in the url on the website (which I found to be consistent with various other already existing atom 1.0 feeds that I checked)), or... well, basically any kind of question that you need to think about as you implement a new and previously unknown specification.

RSS on the other hand (any of the 9 incompatible versions)... *shudders* Those specifications don't tell me anything. I copy/paste from other feeds and heavily use the feedvalidator, but... *shakes his head*
Once all feedreaders have been updated to support Atom 1.0 completely, I'll go and pull the plug on the remaining RSS feeds, and good riddance too!

Patent RSS Feeds

Interesting, but useless. Why? Because Feedburner does not generate valid feeds.

Someday these services will get a clue and realize that the XML spec requires that invalid feeds be rejected.

Patent RSS Feeds

Interesting, but useless. Why? Because Feedburner does not generate valid feeds.

Someday these services will get a clue and realize that the XML spec requires that invalid feeds be rejected.

Patent RSS Feeds

Interesting, but useless. Why? Because Feedburner does not generate valid feeds.

Someday these services will get a clue and realize that the XML spec requires that invalid feeds be rejected.

Patent RSS Feeds

Interesting, but useless. Why? Because Feedburner does not generate valid feeds.

Someday these services will get a clue and realize that the XML spec requires that invalid feeds be rejected.

Patent RSS Feeds

Interesting, but useless. Why? Because Feedburner does not generate valid feeds.

Someday these services will get a clue and realize that the XML spec requires that invalid feeds be rejected.

There's a variety of ways to deal with this issue. The solution many seem to be suggesting is to randomize request times so that there aren't big spikes in traffic every hour at the hour. That's certainly a good idea. Clients should also respect the ttl (polling at the interval that is listed in the feed), support conditional GET, and handle 304 (not modified) responses to minimize the number of requests they make for the full feed.

But the primary solution will end up being caching. With the exception of personalized RSS feeds, RSS feeds easily can be cached. Web-based RSS readers like Bloglines and My Yahoo already only read the RSS feed once, cache it, and display it to multiple readers. But popular RSS feeds are also easily proxy cached just like web pages, reducing the load on the original source servers.