Category Archives: RSS

Bloglines Update

I’m a few days late on this, but I think the new Bloglines updates are really slick, they’re subtle but they really improve the usability of the product. Bloglines is my favority aggregator, online or offline, and I admire the restraint they have. It would be easy for them to add every possible feature, instead they keep things simple and, since January, fast. Simplicity is far harder than complexity. Especially in a big organization.

Conventional RSS

Alex from Textpattern has started putting thoughts down on what we’re calling “conventional RSS.” It’s not a spec, profile, or anything like that. It’s just a documentation of the things we do in our RSS 2.0 feeds. There are some minor differences with what WP currently does, but at least in the beginning WordPress and Textpattern will have a shared set of conventions and assumptions.

The Feed Validator is Dead to Me

Is anyone else sick and tired of the so-called feed validator changing its mind on fundamental issues every other week? I’m sure Sam Ruby and whoever else is still working on the Validator mean well, but the constant ivory tower decisions to change the way it interpets “valid RSS 2.0″ is making it seem more like a political advocacy tool than anything else. Perhaps I should give the benefit of the doubt and “Never attribute to malice that which is adequately explained by stupidity.”

I’m not even talking about deciding they can change the world by decree. (Which has already been addressed.) The latest in their line of enlightened changes is that the author of the Well-formed Web spec has changed the capitializition of the wfw:commentRSS element at some unknown point to lowercase Rss. This arbitrary decision has been codified by the validator, which now reports the millions and millions of feeds that use the previously correct capitialization as invalid. Confusion ensues.

If the previous paragraph makes your eyes glaze over, congratulations, you’re normal.

Here is a post on their mailing list which also explains the issue and includes a link to the archive.org version of the page with the capitialization everyone uses, which was there for at least two years. One line can cause so much trouble.

But wait, there’s more. “In addition, this feed has an issue that may cause problems for some users.” They’ve also started marking all uses of content:encoded as potentially causing problems, which is funny because it actually avoids a ton of problems and (again) people have been using it in RSS 2.0 feeds for 3+ years now, and I even asked Dave Winer about it in the past and he said that was fine. Their documentation on the topic seems more geared toward instilling fear, uncertainty, and doubt in RSS 2.0 than addressing the reason they’ve decided to start warning about this element. Where a validator normally provides stability, the feed validator has become the Homeland Security of the RSS world, keeping us all in a constant state of dulled fear, insensitive to whatever warnings they’re giving us today because we just want it to stop.

I’m sure the content:encoded change can be rationalized with a perfectly convincing argument. I wouldn’t be surprised if someone as smart as Sam could do the same for the arbitrary wft:CommentRSS change. I know that the code is open source and we could fork it and create another version of the validator that doesn’t invalidate half the blogosphere on a Tuesday afternoon. But then we would have more than one validator, and that defeats the point.

Invalid Atom

“Next time someone tells you Atom 0.3 is invalid because the validator says so, point them to this page. The validator is full of it, because it doesn’t reflect reality.” If Robert had comments, I would say “I never suggested Bloglines was “best-effort software development” (though I do love it and use it myself) but merely that it has an overwhelming market share. We’ve been tracking feed stats on WordPress.com and Bloglines and Newsgator online both dominate. The Web Standards project never casts stones from an ivory tower, they’ve always advocated practical standards for pratical benefits. Ben’s comment was akin to someone saying that the site sucked because it used XHTML 1.0 instead of 1.1, or if the validator decided to instantly “deprecate” all sites using HTML 3.2, 4.0, and XHTML 1.0 when 1.1 came out.”