Two different approaches to setting up RSS feeds in ASP.Net MVC

I was actually looking for just one way of implementing RSS with ASP.Net MVC Framework as part of a new feature for GigJunkie (look for the announcement in the GigJunkie blog in a few weeks)…I actually was about to implement this

Brad Abrams : RSS Feed with the new ASP.NET MVC Framework.

when I found this:

ASP.NET MVC RSS Feed Action Result
Which method is better is a matter of opinion. In terms of generating a well formed RSS or ATOM document without needing to know too much details about the standard itself, the 2nd link is better since it uses already established Windows Communication Foundation (WCF) objects such as RSS20FeedFormatter, Atom10FeedFormatter, SyndicationFeed and SyndicationItem to wrap your content inside the appropriate tags within the XML document.

However, there are some limitations to this approach as you are trusting these pre-defined objects to adhere to the defined standard and place values in the correct or expected appropriate position within the XML. This can result in some issues, as for example when I realised that unless declared in the constructor as a parameter, I found no property of the SyndicationFeed object that would directly manipulate the value of the rendered <description> tag’s contents of an RSS 2.0 feed. I had assumed editing the SyndicationFeed’s Content property would apply these changes, however they instead created an <a10:content> parameter which contained my content instead. The reason I needed the <description> values edited are because these are what are displayed in Live feeds inside Firefox and Outlook. <a10:content> although inside the feed, is not rendered in any particular way. A slight variation on how I built the content was required, but still, it was a little annoying to have to discover it was an issue in the first place.

So that means there are still merits of using the 1st link’s method, since you as the developer, are in essence, in full control of ensuring that the View renders the proper parameters and that all ViewData is in the appropriate locations within it. This has its benefits, in cases for example where the standard may change or be upgraded before the Framework objects themselves have had a chance to be updated as well. The counter to this is, of course, that you are also fully responsible for a shoddy implementation of the XML specification if you are not thorough with the RSS and ATOM specification guidelines.