I'm seeing lots of interest in my
MS Feeds API post yesterday, sparked by links from
Sam Ruby,
Dave Winer and
Randy Morin. Some people might have gotten the impression that I was criticizing the decisions Microsoft made in mapping RSS elements and extension elements to the Feeds API object model. I wasn't.
I think Microsoft made pretty good choices, given the simplified object model that they're working with. If somebody is using funky RSS, then they mean it. For example, if somebody declares the Content Module namespace and uses the
<content:encoded> namespace in their feed, then that's probably the content that they want folks to use. I think that's the philosophy Microsoft used in making those decisions, except for prefering
<pubDate> over
<dc:date>, which I don't understand.
The problem is, the Feeds API object model is a little too simple. Like RSS 2.0, it doesn't model the common things that bloggers do like having both a summary and content for each item, or having name and/or e-mail address for each author. That's why people use extensions like the
<content:encoded> and
<dc:creator> (or prefer Atom, which does a better job of modeling those common things). I hope Microsoft will fix this by improving the object model and if they do, they won't have to make as many choices about which elements to use.