Dare on XML vs. Interfaces

"However there is a significant difference which is a consequence of the fact that data typically evolves faster than code. In the past few months significant changes to the RSS landscape have occured with the rise of RSS 2.0, replacement of content:encoded with xhtml:body by some notable RSS feeds and the invention of the CommentAPI. There would be significant API churn and information overload if a new interface was cooked up anytime something new happened in the RSS world and a news aggregator wanted to support this feature."
[Dare's Diary]

This only presents a problem if your domain model is a simple one (ie. it just serializes and deserializes with an XmlSerializer). If you properly design your object model, then it is not a problem at all. Of course, since we are dealing with RSS feeds, using XML is at least debatable (because you are not really having a lot of logic in your domain model, you are just parsing some crap out).

Which solution is better?

public abstract class FeedItem
{
    public string ContentType { get { ... } set { ... } }
    public string ContentText { get { ... } set { ... } }   
    public string ContentXml { get { ... } set { ... } }

    // ...
}

public class MyParser : IFeedItemParser
{
   public void ParseItem(FeedItem item)
   {
       SendItemChangeNotification("someone@microsoft.com", item.ContentText, item.ContentUrl);
   }
}

public class MyParser : IFeedItemParser2
{
   public void ParseItem(XmlNode item)
   {
        XmlNode encodedContent = item.SelectSingleNode("content:encoded");
        XmlNode xhtmlContent = item.SelectSingleNode("body:xhtml");
        XmlNode plainTextContent = item.SelectSingleNode("description");

        if(encodedContent != null) { ... }
        if(xhtmlContent != null) { ... }
        if(plainTextContent != null) { ... }
   }
}

In the first example, the burden of supporting additional content types is left to the application (where it should be). In the second example, the burden of supporting additional content types is left to each individual author, which produces lots of extra, useless code. This isn't to say that the burden has to be on the application though, because you could easily allow extension of the content decoders as well (and, if you are worried about new elements being introduced, it ain't rocket science to add support for xml based handlers which can add additional attachments to the FeedItem object). Option 1  is far superior because a simple update to the application can ensure that all your plugins continue to work, regardless of changes in the xml spec. Call it tightly coupled if you want, but proper coupling produces systems that are easier to work with...