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
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.
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.
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)...
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...