Okay, we've got all of the formats mapping to a basic Atom 1.0 format

[M. David Peterson]

As per my recent (second to last) check in note:

this gets us about 2/3rd's of the way.  Still need to write a date conversion utility, and then deal with all of the serialization issues, as well as the mapping of attributes from Atom 0.3 to 1.0.  There's also a need to (after proper serialization of the data contained inside of the description tag of RSS+RDF, and the other Pseudo RSS format.

Will deal with the rest of this tomorrow.

Related files: http://xslt.googlecode.com/svn/trunk/module/feedAggregation/

The last check-in note:

current snapshot of the output that is produced for an Atom 0.3, RSS+RDF, RSS "2.0", as well as an existing Atom 1.0 feed.

The current output can be see @ http://xslt.googlecode.com/svn/trunk/module/feedAggregation/output.xml

Just so you all know how this relates directly to the Blip Messaging efforts, once this aggregator is complete, this will allow the ability to use any current blogging engines that emit at least one of the above formats to create the initial message to then convert this to the Atom 1.0 format such that we can then more easily map the generated feed to the Blip Message based on the Atom Notifications format.

So while I truly was aggravated by CodePlex aggregation tool, the reality is that this needed to be developed anyway, and this just spurred the effort to get it done and out of the way such that we can use it for our development and testing from here on out.

Chat with ya'll in the morning :D

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354

[M. David Peterson]

>> "There's also a need to"

should have appended to it

>> "generate the proper type attribute value of the content element based on the determination as to what is contained inside of the RSS 'description' element."

If not mistaken, the description element does not specify how to go about adding HTML, XHTML, or XML, and in fact technically speaking, can only contain simple text, which forces the need for the use of the CDATA block to provide the equivalent of a simple string (to be honest, I don't remember all of the screwy details, nor do I care to remind myself -- There are enough RSS feeds that use CDATA blocks no matter what is contained inside the description element to realize this has become the standard way to to handle this.)

So with this in mind, attempting to make sense of whats really inside to then make the conversion such that we can avoid using CDATA blocks all together seems to be the ideal solution.

Anybody care to comment as to whether or not you feel its worth the effort?  I'm open to do whatever, as long as its the right decision for the long term needs, so please, by all means -- comment away :D