Month: January 2004

Sam Ruby proposes that aggregators validate on subscription, and I have to confess that this makes more sense than my stated position of requiring Atom feeds to be well-formed.

What Sam suggests is that aggregators such as FeedDemon inform of validation errors only when first subscribing to a feed. After informing the user of the fact that these errors might affect how the feed displays, the aggregator should continue to subscribe and not show any further indication that the feed is invalid. The hope is that this would gently persuade feed creators to pay attention to validation problems without stopping end users from reading invalid feeds.

After accepting that Sam’s idea makes more sense than my own (which took all of two minutes!), I started coding this into FeedDemon. When a user subscribes to a feed, FeedDemon checks it for well-formedness, and if any problems are found the dialog shown below is displayed:

Clicking the “Details” button shows the text of the validation error, and a link to the online Feed Validator provides a way for authors to check the feed for additional problems.

My hope is to include this in the next build of FeedDemon. As always, I’m open to other suggestions, so please post a comment here if you think this can be improved (or if you think it’s a bad idea altogether).

Last night I stated my position on well-formed Atom feeds, but I’m not sure I did a good job of explaining myself.

The point here isn’t that I’m trying to save myself time by requiring well-formed Atom feeds – I’ve already written a forgiving RSS parser which could easily be adapted to handle Atom, so this will actually take me more development time. And while I agree 100% with the position that users don’t care about well-formed XML, the point is that parsing malformed feeds will require users to care later on.

With both HomeSite and TopStyle, I’ve seen first-hand the problems that customers deal with due to the way different browsers handle HTML and CSS. If you’re a web author, no doubt you’ve wasted countless hours trying to get your pages to look right in multiple browsers. Instead of pulling your hair out over cross-browser inconsistencies, wouldn’t you rather have spent your time creating a great site?

So it is with Atom. If you have a blog (and if you don’t, chances are you will in the next year or two), your focus is on writing interesting content. Now, what would you do if your newsfeed didn’t work right in different aggregators? Perhaps one aggregator showed the right content, but your spacing is all screwed up. Or another got your spacing right, but has HTML entities such as & and < spewed all over the place. And another aggregator shows your post just fine, but the link to your site doesn’t work. This sort of thing already happens with RSS, and it’s frustrating to blog readers and writers alike.

Would you really want to devote time to tracking down these problems? Web authors have to deal with this situation today, and it’s a royal pain (in fact, I created TopStyle to help web authors solve these problems). Wouldn’t it be nice if bloggers didn’t have to face these same issues down the road?

Now, keep in mind that the vast majority of Atom feeds will be produced by blogging tools rather than hand-coded. By requiring well-formed Atom feeds, FeedDemon and NetNewsWire give the blogging tool creators a very strong incentive to create well-formed feeds – they don’t want to deal with customer complaints about their feeds not working in aggregators. By taking this position now – when Atom is in its infancy – we can avoid the problems that have plagued web authoring, and enable both content creators and end users to focus on great writing.

Update: I’ve compromised on the above position.

NetNewsWire creator Brent Simmons recently announced that NetNewsWire’s future support for Atom will require Atom feeds to be well-formed. Some people aren’t too happy about this, claiming that he’s applying a double standard that will make Atom appear less useful than RSS.

So, I’ll add to the stink by stating that my plan is the same as Brent’s. FeedDemon will also support Atom, but if an Atom feed isn’t well-formed XML, FeedDemon will display an error rather than try to parse it. In fairness I have to consider this decision open to input from my customers, but I want to explain why I believe this is important.

When I started coding FeedDemon, I immediately ran into an ugly problem: a huge number of RSS feeds are invalid. This made it impossible to use an off-the-shelf validating XML parser, since it would choke on so many existing feeds. A number of very popular RSS feeds are shockingly invalid, and I couldn’t expect FeedDemon to compete in the RSS aggregator market if it couldn’t handle them. So, I coded my own XML parser, and made it extremely forgiving of problematic feeds.

Atom, however, is a new format, and there’s a chance we can get it right. Rather than wasting our time working around validation issues, aggregator authors such as myself can spend our time coding the features our users really want. This isn’t just self-serving on my part: it will make it easier for anyone who wants to consume Atom feeds if they can expect them to at least be well-formed. It’s not like well-formed XML is hard to do – Tim Bray has listed the four “Bozo Factor” rules that are required, and I have to think that anyone who can spell “XML” can follow these rules.

If both NetNewsWire and FeedDemon require well-formed Atom feeds, then perhaps we’ve provided authors of Atom feeds enough incentive to spit out valid XML instead of the tag soup that has infected too many RSS feeds.

Note: Be sure to read part II of this topic.