public virtual MemoryStream

Mark posted an entry a few weeks ago called The myth of RSS compatibility in which he outlined the 9 different versions of RSS and how they are incompatible with each other. While I'm sure his article is technically correct, in practice it's not that hard to write a single parser that handles all formats of RSS. Such a parser may not be 100% correct according to all the 9 different specs, but it will handle the vast majority of available RSS feeds without a problem. SharpReader implements such a parser and I assume most (if not all) other aggregators take a similar approach as it saves the writer a lot of duplicate coding for shared tags and extension namespaces like dublin core.

In the design of the new ATOM format, it was decided to start from scratch with a new format instead of basing it on the existing RSS tags. This way ATOM breaks free of the incompatibilities, under-specification and in-fighting that often occurs around RSS. The unfortunate downside of this is that ATOM feeds cannot be handled by existing RSS parsers, whereas an RSS 2.0.2 (should there ever be one) would be backward compatible enough to be read by existing parsers that already handle the 9 current dialects.

Building an entirely new parser for ATOM did not seem very appealing to me, especially since the ATOM spec is currently only at version 0.3 and is bound to undergo quite a few (backwards incompatible) changes before reaching 1.0. Because of this immaturity of the spec, I had initially planned not to support ATOM until it reached 1.0.

Mark's decision long ago to cripple his RSS spec (while keeping an ATOM feed containing everything that used to be in his RSS feed) made me temporarily consider implementing ATOM, but since diveintomark.org was (back then) the only site I knew off where the ATOM feed contained more information than the RSS feed, I decided against it. Then recently Blogger decided to add ATOM feeds to all their blogs while keeping RSS a pro-only feature.

While I personally do not understand the reasoning behind Blogger's decision (why use an immature spec that is not yet widely implemented and is still in flex, when there is a widely implemented and mature alternative that will do everything you need it to do?), it did force me to reconsider my initial decision as there are now many thousands of blogs with an ATOM feed that do not have an equivalent RSS feed.

I have therefore added support for ATOM to the next version of SharpReader (due out soon) and I'll just have to bite the bullet and keep updating my code-base as new versions of the ATOM specification come out. In order to allow ATOM feeds to use the same extension namespaces that I already implemented for RSS, I have decided against creating a separate parser, but instead integrated the ATOM bits into my existing RSS parser. This effectively means I'm treating ATOM as if it were just another RSS namespace extension (with quite a few funky elements): <atom:feed> is treated as a <rss> tag, <atom:entry> is like <rss:item>, etc. A nice side effect of this implementation is that it will allow people to add ATOM elements to their existing RSS feed and vice versa, which I believe should be allowed anyway according to the standard namespace extension rules.