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.
It’s not just open source, it also has a mailing list. Have you raised your concerns there?
Hrm. I certainly disagree with some of the choices Sam and the rest of the validator developers have made. OTOH, it’s made many changes to all of the formats. The fact of the matter is, the locus of “valid” and “works in aggregators” changes all the time. I think your post is a little too raging, since I believe the validator generally does a good job. I certainly value it when I triage bugs in Mozilla. On the other hand, I have the background to know whether I should pay attention to it.
That said, I do have a big problem with the duplicate element semantics message, in particular the message from James Holderness, where atom:content vs. content:encoded is used as a testcase, and Thunderbird is used as an example, even though the behavior he found is a *bug* (a regression that I introduced, and will be patched for 1.5.0.2).
I think the Feed Validator has strayed into advocacy and even spec-writing a few times, and that sucks.
I can’t recall when I stopped pointing members to it on the support forums because of this stuff, but it’s been a while. Keep in mind the w3.org validator currently produces a warning about content:encoded, though the feed passes validation. Not sure if that’s politics leaking into it over there as well or what, but at least one still gets the snazzy button!
If only that were true. I would offer a word of caution about asking Dave something involving RSS, though. That has had mixed results in the past.
I think of the Feed Validator as one of those things you use during development, and no other time. You don’t put a button to it on your site, and you don’t run other people’s feeds through it.
If you develop and app that generates yesterday’s RSS 2.0, all power to you.
Quote of the month material right there… god I love it…
Glad to see this post. I was farking around with Drupal at work the other day and it started telling me I couldn’t add a WP RSS feed to its aggregator module because it was invalid. I jumped to the validator, thinking it couldn’t possibly be, and lo and behold it was. I was too lazy to research it, but this answers my question. Thanks!
Matt,
I’ve been battling similar problems for a long time. The RSS spec is full of ambiguities, and every man and his dog has a different opinion as to how to resolve each one. I decided to keep Textpattern at RSS 0.92 until the most pressing issues were clarified, and I’m still waiting.
Enough waiting already. Let’s show them how it’s done. I’ve proposed a simple list of best practices for RSS feed producers. Perhaps if the WordPress and Textpattern teams can agree on a few basic rules and clarifications, others might follow.
I’m quite happy for Txp to follow WP’s lead on those issues you guys have already decided. I’m not really concerned with what the answers are; merely that we have some answers in the first place.
The commentRss spec changed. The feedvalidator changed accordingly.
Dave published his “busy developers guide” for RSS. The feedvalidator changed accordingly.
The feedvalidator validates against the specifications as written. The “About the Feed Validator” page doesn’t say anything about validating common practice.
Matt, they’re using the feed validator to make their case that everyone should switch to the ‘well specified’ format that they designed. It’s pure politics. Until Sam Ruby gives up control of the feed validator it should be seen as a vehicle for furthering his politics.
While this has nothing to do with the feedvalidator, I wanted to tell to you that the column is so wide that it makes the entry difficult to read.
And the big deal is? So you need to commit a 2-character change to
wp-rss2.phpin order to comply with a change that was made to the validator in order to comply more accurately to the spec (which had not changed; it was merely inaccurately quoted on the archived page you linked).I don’t envy Sam. He’s damned if he does: “everyone does it the marginally spec-violating way and it still works,” right? So the validator should not make a fuss out of political issues!! And he’s damned if he doesn’t: dude, the spec is clear on my pet peeve! Where the hell does Sam get the audacity to decide that something is common practice and the spec may be ignored?!
Unfortunately, the validator is software, and you know what, software has bugs. With the role of the validator, that fact becomes a precarious situation. Is the validator bug that can be named an eternal validator bug? Not in fact, as noone cries foul when bugs in the HTML and CSS validators are fixed. The reason that the Feed Validator is not a paragon of stability the way they are is merely a reflection of the fact that, suprise!, the syndication space is highly politicized.
I’d like to know what practical alternative you propose to Sam’s approach of coping with the cognitive dissonance of his position. To me, the course he has relatively consistently taken appears to be the only one by which he can plausibly claim neutrality, which, as he knows very well and you do also, is crucial to the Feed Validator’s credibility.
Matt,
I changed nothing about the specification, which is originated and controlled by Chris Sells, and hasn’t changed in two years[1]. In putting together a single page I made a typo. When my mistake was pointed out to me I corrected the typo [2][3]. As I stated before, if i had known how widespread the use of the wrong commentRSS was I would have made a bigger deal of it. So much for ‘view source'[4].
So my behavior can be “adequately explained by stupidity” on my part, i.e. I’m a moron.
I’ll leave it up to you to pick which word best describes you[5].
[1] http://web.archive.org/web/20050301040756/www.sellsbrothers.com/spout/#exposingRssComments
[2] http://groups.yahoo.com/group/rss-public/message/593
[3] http://www.blojsom.com/blog/nerdery/2006/01/31/wfw-commentRSS-right.html
[4] http://wellformedweb.org/news?rss
[5] http://diveintomark.org/archives/2004/08/16/specs
Downgraded to a warning.
I can understand your frustration. Right now, no matter what you do, your feeds may not work in some aggregators. But that’s not the fault of the feedvalidator. Sam has no choice but to validate against the spec and, unfortunately for you, the spec says that commentRss was the right choice and commentRSS is wrong.
The good news is that if feed producers do pay attention to what the feedvalidator is telling them, and aggregator authors do follow the spec correctly when reading those feeds, there will one day be interoperability. However, if people choose to ignore the feedvalidator warnings, we’re going to be stuck with this mess forever.
You have the power to make things right. It might be painful at first, but it’s the only sane way forward.
“I’m not even talking about deciding they can change the world by decree.”
Deprecating 0.3 isn’t issuing a decree… it’s the obvious move implied by the “0.3” bit. Publishers who continue to produce 0.3 feeds are perpetuating the problem Atom was intended to address.
RE: wfw:commentRss
A quick look at my blog entry about it from April 2004 indicates that *someone* was already pushing the camel-case version, ’cause that’s what I was using. I honestly have no idea what convinced me to go that way instead of the other… app compatibility tests, I guess.
“Their documentation on the topic seems more geared toward instilling fear, uncertainty, and doubt in RSS 2.0…”
I’m a fan of RSS 2.0, but c’mon… cut people a break. Dave has stated over and over that any extension element that duplicates a native RSS 2.0 element is “funky” and shouldn’t be used. Now that he’s also declared that rss:description contains entity-escaped HTML, we have funk. That you’ve received conflicting messages from Dave is not the validator’s fault.
I’m afraid this seems rather like shooting the messenger. As I understand it, the purpose of the validator is to show how a particular feed lines up against the relevant specifications. If the specs change, so should the validator.
Personally I’ve rather check mechanically against the validator rather than trying to keep track of all the relevant specs (and sometimes contradictory advisories that crop up on certain blogs). I’ve far rather attempt to follow the specs than try and monitor the behaviour of all the feed readers on the planet, and the validator makes that feasible.
Yep, its been a problem in a lot of ways. I agree 100% – http://www.rss-specifications.com/mar-blog-2006.htm#444
“For every complex problem there is a solution that is concise, clear, simple, and wrong.” “” H. L. Mencken
Mark Pilgirm and Co. have been wielding the feed validator as a weapon for a long time. It’s unfortunate, but so it goes. Rememer this kids first foray into computer technology was to write a virus. They aren’t in this to be nice!
Yeah! What he said. Specs are stupid. Validators that validate against well-defined specs are stupid. Whatever seems like it mostly works in the wild, that’s what the spec really is, not some pinheaded engineering document full of stupid prescriptive definitions. Details are stupid, blogging r the fun! Wheeee.
Moreover, make em say unnnnh… the idea of parsing liberally and writing specifically is stupid too. What works just works, so write whatever you feel like, specs are stupid and standards are standards. CSS is stupid, XML is stupid, HTML4 is stupid, XHTML is stupid, Rumsfeld is stupid, you mom is stupid, AJAX is stupid, everthing is stupid, DHH is stupid, this post and my comment are each terminall stupid.
Don’t hurt em, Hammer.
The thing that annoys me so much about the feed validator itself, it’s about the underlying problem that there are no explicit, completely unambiguous specs out there. (Are there? Where are they?) I’m not talking about a few paragraphs of text on some Harvard website, or some hodge-podge of Dave Winer posts. I’m talking about public, error-free, set-in-stone schema and/or DTD documents that perfectly lay out RSS and related fields. If the W3C can do ’em for much more varied things like xhtml while can someone do ’em for RSS?
“I’m talking about public, error-free, set-in-stone schema and/or DTD documents that perfectly lay out RSS and related fields. If the W3C can do “˜em for much more varied things like xhtml while can someone do “˜em for RSS?”
First of all, the W3C DTDs and schemas are a lot less precise than the feed validator. Second, what makes you think that a schema that was as precise as the feed validator would be less prone to errors than the Feed Validator? Do you really want things set in stone more than you want them to be correct? And besides, if you consider Python as a schema language, Feed Validator already is what you want. 🙂
Not for RSS, no.
Chris Spurgeon, I hate to bring this up, but you know there *is* such a spec for Atom, right? The lack of an RSS spec is one of the very reasons for Atom’s existence, and its spec is a reflection of that.
If RSS were a W3C standard, they probably would have issued something by now. But since RSS has never been submitted to them or any other standards body, we have only had the Feed Validator to rely on. The irony of all this, of course, is that every time this sort of issue comes up, RSS 2.0 supporters take one side, non-supporters take the other, and the uninitiated (if they can even follow it) only become more and more confused.
… 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.
I can’t believe that you (and so many others) would prefer for the Feed Validator to ignore the spec change on the grounds that it’s “arbitrary.”
What have you done with the Matt Mullenweg who cares about standards?
All together now: Chris, you must be new around here.
A coupla things…
– To my knowledge, every pre-1.0 IETF-wg Atom feed draft had do-not-deploy language attached. In line with what Roger Benningfield said, if that’s a “decree”, then so is gravity.
– Building a validator against what, in many cases, are glorified napkin sketches, is a thankless job.
Chris Spurgeon wrote
“it’s about the underlying problem that there are no explicit, completely unambiguous specs out there. (Are there? Where are they?) I’m not talking about a few paragraphs of text on some Harvard website, or some hodge-podge of Dave Winer posts. I’m talking about public, error-free, set-in-stone schema and/or DTD documents that perfectly lay out RSS and related fields. If the W3C can do “˜em for much more varied things like xhtml while can someone do “˜em for RSS?”
I haven’t ever seen error-free, perfectly laid out specs from especially not the W3C. That said, Dave Winer’s family of specs could use a formal erratta process which is what mainly separates specs from organizations like the W3C from informal specs [or even IETF specs which seem to require an entirely new RFC to fix bugs].
As my post on the Feed Validator user forum is one that is linked to in the post, I offer my own view on this whole issue.
I don’t write code and I don’t know RSS feeds from underground cavities. I chose WordPress content management for my weblogs because everyone raved about how it took 30 minutes to get a blog published so anyone could read it. And it did.
So I gently offer this: While you are all questioning correct capitalization and all, I — as well as thousands of others I imagine– don’t know about the code and don’t know how much to care. I just want my blog to be readable in a number of formats. I don’t know whether this validator or another indicates that my blogs can be read by people as cheerfully ignorant as myself, or can’t be read at all.
As with all other areas of communication, people who “do” don’t necessarily teach. As you are blissfully producing best practices, the general public is tripping down the RSS road not knowing what’s going on in the background — and not really knowing if they should care.
Please, before you change something, keep in mind that those who are affected don’t know why it’s important, how to respond to it, and don’t know how to change our “stuff” in response to it. You are speaking a technical language and using technical documents and skills that skips right over the otherwise intelligent heads of the people who aren’t privy to this knowledge. Don’t change something until or unless it’s really, really important to change it. Bear in mind that there’s a resultant domino cascade for elemental users like me.
Unless you’re doing all this for those who knew the secret handshake at birth, I’m the guy you’re doing all this for.
“I chose WordPress content management for my weblogs because everyone raved about how it took 30 minutes to get a blog published so anyone could read it. And it did.”
Catherine: If that’s your priority and/or skill level, then don’t worry about validation. I could probably pull the diagnostics on my car tomorrow and find dozens of obscure things that need tweaking, but I don’t know much about cars… so why not just drive it until something I can see and understand goes wrong? Yeah, I could get better mileage and performance if I fussed over the small stuff, but that’s obviously not important to me… if it were, I’d learn more about my car.
“…and don’t know how to change our ‘stuff’ in response to it.”
You shouldn’t need to… that’s a job for your app vendor. If the vendor refuses to fix the app, find someone more responsive to supply you with what you need.
d.w.:
0.3 was not an IETF draft, though (it’s how far the first group got on the wiki before switching to the IETF process), and had no such language.
Dare:
If Winer was receptive to such an idea, there would be no Atom.
As long as RSS 2.0 is based on a “human specification” problems will keep comming. The main advantage of Atom is not technical, but political. The Atom specification has a well know process of reviewing, unlike RSS 2.0.
Good Nietzsche quote : )