It’s just data

Undecipherable Specification Error Redux

Last June, I wrote about a some ambiguities in an Apple spec that were troubling me.  More troubling than the ambiguities was the lack of an ability to have a conversation.  So I decided to raise a flag.

The technique worked.  It took multiple iterations, but the point is that the spec got clarified, and the Feed Validator was updated to match.

Now it is time to do it again.  Hopefully it will work out just as well this time.

Meanwhile, results from other validators: scripting, kbcafe, w3c.  Note: only kbcafe is a completely independent implementation, the others are different snapshots of the same codebase.


I went with the assumption for FeedTools that some people would supply multiple enclosures, and that therefore multiple enclosures should be supported regardless of whether it was valid to do so according to the spec or not.  It’s obvious what they meant, and it’s perfectly valid to have multiple enclosures in Atom, so it makes a lot of sense to handle enclosures similarly for all of the feed types.  I think I would strongly argue that failure to handle the possibility of multiple enclosures is wrong unless the spec specifically and clearly says otherwise.  And if the spec specifically says otherwise, then the spec is wrong.  :-P

Posted by Bob Aman at

I think I would strongly argue that failure to handle the possibility of multiple enclosures is wrong unless the spec specifically and clearly says otherwise.

Which spec?  Read through all the discussions referenced on this feedvalidator documentation page.  Then read the change notes for the RSS 0.93 draft.  Then look through this list of aggregators and tell me which ones are “doing it wrong.”

it makes a lot of sense to handle enclosures similarly for all of the feed types.

Totally agree.  My Universal Feed Parser has always handled multiple enclosures per entry, in the sense that it captures all enclosures for each entry and stores them in a list, entries[j].enclosures.  Not that anyone has ever accused me of slavishly restricting UFP to the quirks of one particular spec, but anyway, it supported multiple enclosures even before Atom.  (BTW, the latest feedparser CVS introspects into (X)HTML content to find rel="enclosure" links, and maps them to entries[j].enclosures as well.  It also contains a complete hCard parser, but I digress.)

Anyway, this entire discussion about who said what to whom in which RSS spec, while amusing to watch from the sidelines, is ultimately irrelevant for consumers.  Entries in Atom feeds can contain multiple rel="enclosure" links; (X)HTML content can contain multiple rel="enclosure" links.  Clients that support Atom should support multiple enclosures.  Clients that don’t support Atom are irrelevant.

Which just leaves the small matter of RSS validation, but that’s Somebody Else’s Problem now.

Posted by Mark at

I meant to refer specifically to RSS 2.0.

(X)HTML content can contain multiple rel="enclosure" links.

Which reminds me that I need to get around to adding support for those.  And for bitTorrent links.

Posted by Bob Aman at

links for 2006-02-23

forgetfoo. — Kinja Card: FoO   (tags: kbcafe) Thought Flickr’s : I am dissappointed with Dave Winer (tags: rss rssboard davewiner) Business 2.0 Says iotum is Helping to Reinvent the Web — Alec Saunders .LOG (tags: ibt4im iotum)...

Excerpt from My Weblog at

sphere.com is live!

We have another blogosphere search engine. Considering how broken blogosphere search currently is, the competition is welcomed. Unfortunately, sphere.com doesn’t seem to be doing any better. It’s dominated mostly by splogs, even when I sort by...

Excerpt from The RSS Blog at

Sam Ruby: Undecipherable Specification Error Redux

[link]...

Excerpt from del.icio.us/tag/feedvalidator at

Add your comment