Simon Fell > Its just code > rssFragment

The BlogThis interface is passed an rssFragment, but I haven't yet talked about what's actually in that fragment. What I'd like is for the aggregator to normalize the source data (as this is something it's already worked out), so that the plug-in doesn't have to cope with the wide range of rss versions, modules and extensions floating around.

The normalized fragment will be based on RSS 2.0, and its root is an item element.

At minimum the title and link elements defined in that spec should be passed through if present in the source (allowing for reasonable mappings if the source isn't rss 2.0).

pubDate and/or dc:date if present should be normalized to a dc:date element

which just leaves the content, I'm going back and forth on this one, originally I was thinking that the aggregator should normalize description / content:encoded / xhtml:body to a single content:encoded element. I'm less sure now, I can see that some people might be offended by the loss of fidelity in the xhtml:body -> content:encoded transform. Anyone have any strong opinions one way or the other on this one ?

And finally to clarify one other point, I'm assuming that the plug-in will present/manage any UI required, not the aggregator, i.e. all the aggregator has to do is collect up the data and pass it to the plug-in (this took about 100 lines of C# in Synderilla, including the automatic plugin discovery code). I want this to be drop dead simple for the aggregator writers to support.