Currently, the feed translator uses straight xml parsing to read the rss feed and generate the atom feed. Personally, I'd prefer to use a more object-based approach, so I looked around at some of the rss frameworks, such as Jerry Maguire's RSS 2.0 Framework or RSS.Net. These appear to use the same idea I had, just putting them into objects.

I thought a little more about it, and had the idea of just using an xmlserializer instead. I mean, the feeds are xml, they should conform to a schema, whether it exists, or not, so why not just read the rss feed in, then deserialize it into an object graph. I could then do an object mapping into a different format, such as ATOM, then serialize it out.

All I need are schemas for the different formats. Hmmm... A little searching on the internet shows that there aren't any schemas for RSS. Interesting. What I needed to do was to generate an xsd from some example rss files, such as mine, Ian White's, Rory Blyth's and Dave Winer's. But, how to do it? XMLSpy has this capability, but I don't want to install that nastiness onto my computer. So, a little further searching on w3c.org yielded Microsoft XSD Infererence 1.0. Downloading the appropriate rss feeds, then running the command-line utility gave me an xsd. I then used XSD.exe to generate a cs file containing the types. After including it in my project and putting the following code in:

XmlReader reader = new XmlTextReader(url);
XmlSerializer ser = new XmlSerializer(typeof(Com.CoreyHaines.RSSTypes.rss));
Com.CoreyHaines.RSSTypes.rss r = (Com.CoreyHaines.RSSTypes.rss) ser.Deserialize(reader);

I was able to deserialize the feed. The one problem I ran up against was the the inferer utility generated a schema for the elements. I don't have the best experience with schemas, so I'm trying to figure out how to get the element to just map to a string. I tried altering the element in the schema to be a string, but that yielded a null value in the deserialized graph. Anybody know how to do this? Please let me know in the comments.

[Of note: I went through the trouble of finding a utility that would infer a schema from a set of xml documents, then, when I tried to run xsd, I realized that it could do the same thing for me. Doh!]

I spent all day working on it Saturday, then was having trouble deploying it. To top it all off, I came down with some sort of painful death disease Saturday night and spent all day sunday moaning and groaning (much to the consternation of Mary) and watching football. Today, though, I'm taking the day off of work to rest and recover totally. One of the benefits is that I can work on the feed translator a bit. So, it is working now! Hurra!

http://feedtranslator.coreyhaines.com/feedtranslatortest.htm

Right now, it only supports a subset (basically my dasBlog RSS feed to the dasBlog Atom feed) of RSS to Atom. It is also pretty slow.

For more information, here's my original post with the idea behind this and a follow-up.

If you try it and find any problems, please let me know in the comments for this entry.

For further explanation of what I'm talking about here, please see this post.

I'm almost done with the Feed Format Translator web service. Currently, I have it running on my local box, but I'm having trouble moving the webservice up to my web server, which is hosted at webhosting4life.com. I tried setting a web application and a subdomain, then had my web.config have customErrors mode=”Off”, but it didn't help, so I can't seem to get information about the error it is having. Frankly, I've not too much experience elevating asp.net application, since the majority of what I write are components and winform apps.

Here's the URL for the test harness, maybe someone would want to help me. http://feedtranslator.coreyhaines.com/feedtranslatortest.htm

The code is very brute force right now, doing a straight translation between my RSS feed and my ATOM feed from dasBlog. I'm planning on getting down and dirty with the specs, themselves, and writing a more generic mapper. But, that is for later.

[Update: I've got a proof of concept of this working, here's the post about it and a follow-up. Or, go directly to the proof of concept test page: http://feedtranslator.coreyhaines.com/feedtranslatortest.htm]

[Update: Doh! For some reason, my post on this topic got lost and the permalink pointed to my post about Google's answering of the "What is the matrix" question.  I guess I'll have to rewrite my RSS vs. Atom idea].

Scoble points to Evan William's blog and points out that Blogger now supports the Atom syndication format. He asks the question about why Atom instead of RSS. Going further, he, rather facetiously, I hope, asks whether Microsoft should create its own syndication format. :) Currently, MS is supporting RSS 2.0.

Personally, I think the whole RSS vs Atom debate is starting to sound like the HTML standardization debates between IE and Netscape supporters. People are talking about making a standard and having everyone support it, but we all know that human nature isn't like that. Everyone is going to make their own format. Here's my solution to the whole problem:

Create a web service that sits in a central location and is responsible for transforming between formats. If I use a reader that only reads RSS formats, and I want to read an Atom feed, I will point my reader to this web service instead of the Atom feed. The web service will be responsible for taking the URL, reading the feed, then transforming it into the requested format (in this case, RSS). Now, if someone much smarter than I am decides to come up with a totally ass-kicking new syndication format, a transform engine can be written between the new format and other ones. Now, if this web service also supports a rich API for plugging into it, also allowing the transform engine to be a web service, then the author of the format could simply write a transform web service and point the central service to it.

So, to summarize:

• People are selfish, standards fragment and split.
• We need to have a central place to transform between formats so that each individual blogging system can choose to support whatever format they want and not have to worry about supporting all of them.
• Web Service which controls transformations from one syndication format to another.
• Well-defined plugin API, so syndication authors (or others) can write transform engines between their format and others.
• Plugin API should support both component-based and webservice-based.

In one word, BabelFish.

[Update 2]

Dare Obasanjo has a take on this which I don't totally agree with. His idea tends toward moving from RSS 2.0 to a newer, standard syndication format. Again, I think that working on a global standard is only leading to more turf wars, rather than working towards working in our diverse world.

For all the web developers out there, wouldn't it have been great to have a service that would translate your web page to support netscape and ie and opera and all the others? Admittedly, HTML was a bit more complicated, especially when you started adding dynamic stuff with javascript. A syndication format, though, is definitely much simpler than a layout language, so I think this could be possible.