With an eye toward gathering some more facts on how relevant this is, I decided to take another walk through my feeds. I posted some data on enclosure usage the other day; today, I figured I'd take a look at the distribution of formats being used in my collection of feeds.

So, I subscribe to 316 feeds. I ran some simple workspace code to get an idea of what formats are in use:

I'm not surprised that RSS 2.0 is the most prevalent, but I take that data point as an argument in favor of clarifying the RSS 2.0 spec in the areas that are ambiguous - which is opposite the tack that Dave Winer takes. Right now, Atom answers questions about things like number of enclosures and format of the content (description) field conclusively. Which means that tool developers have a default answer that is correct for that format - they don't have to make a (personal) judgement call (which, as Rogers Cadenhead pointed out on the mailing list, varies widely across tools).

Now, I suppose that I could just ignore this, on the following grounds:

1. Aggregators support RDF, Atom, and RSS (all versions)
2. Atom allows for multiple enclosures
3. Developers will likely support one data model in their tool for all flavors
4. Over time, given Atom's stance, that will move developers toward supporting multiple enclosures

Sadly, the same thing can't solve the other problems - questions about what is or is not valid for description or title elements. Perhaps developers could simply take the Atom answer for titles, but for content, Atom relies on a description in the field. That means that developers can't just apply the Atom answer and have done with it. What it does mean is that every developer has to come up with a strategy, and (as we've seen to date with enclosures), those answers will differ. I suppose that leaves the end user in the driver's seat as far as deciding which answer is best, but it's not the best way to come up with an answer. Having the spec clarify what is and is not allowed would be a whole lot simpler.