As an format that is not intended for publishing on the web, but which is really a contract between the platform and the clients of the platform, the native format we use is not really required to be "pure" RSS 2.0. As I said, we use RSS 2.0 as the basis for the native format to leverage developers understanding of that format. I don't think that the addition of a single attribute to an element quite invalidates the entire premise, but if it really upsets everyone, we can put it in a namespace.
Obviously, the further off the beaten path you get from typical feeds, the less like a pure RSS 2.0 feed it will look. Especially in the case of Atom 1.0, we detect various cases that aren't supported by RSS 2.0, and model them as extensions. Binary content is an example where we'll include the entire atom element as an RSS 2.0 extension in the feed. Since RFC 822 doesn't support sub-second times, we'll truncate those in the XML we return, but the sub-second times is available via the object model, if an application needs it. Right now, we don't support multiple enclosures, so representing it in the XML isn't an issue. When we do - in a future release - we could include multiple enclosure elements in the XML, or create an extension (or leverage the Yahoo Media RSS extensions). At the end of the day, I'll readily admit that complex Atom 1.0 feeds won't look pretty in RSS 2.0+Atom-extensions. That said, the vast majority of all Atom feeds on the Internet today convert to RSS 2.0 with zero issues. I'll repeat what I said in a different response: This isn't the end of the API set, and this feedback is useful to figuring out what needs to happen for the next version. Thanks, Sean -----Original Message----- From: Sam Ruby [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 5:32 PM To: Sean Lyndersay Cc: Atom Syntax Subject: Re: Fwd: [rss-public] Microsoft Feeds API Enclosure Test Sean Lyndersay wrote: > > The normalized XML that you're seeing in View Source is also > accessible from the feed APIs, so the XML we generate is a format we > expect to support in perpetuity. > > It's designed to be a relatively simple format that application > developers can rely on in the same way that they rely on APIs in the > object model, so we map all common elements from other formats into > RSS 2.0 (the basis for our native format). Why RSS 2.0? Because it's > the format used by the majority of feeds on the web. >From reports I have seen, you are doing things like adding type attributes on >the description element? If so, it isn't RSS 2.0. How do you plan to handle multiple enclosures? How about HTML in titles? On Feed-Tech I saw a post by Phil Stanhope indicating the importance of sub-second times in certain scenarios. How will this be expressed in RFC 822 format? How about content that is in a binary format? I can go on... > Any case of data-loss is a bug that we'll address If that is a blanket statement, then I expect that you will be seeing a lot of bug reports. - Sam Ruby
