Jon Udell, lead analyst/blogger at the InfoWorld Test Center, wrote a fascinating article in the Nov 28/05 print edition of InfoWorld (hyperlink below) called "The Two-Way Data Web".

Udell says that the Atom and RSS web feed formats have already been used to create blog databases, and that "Atom and RSS are evolving into tools for creating loosely-coupled databases on Internet scale."

He feels that XML/RSS/Atom web feeds might one day become two-directional. That is, not only readable but writeable. Now, you may be saying that blogging tools already let you read/write an RSS feed, and you'd be right. What Udell says, though, is that "RSS as a data transport remains largely asymmetric."

He goes on to indicate that it would be nice if there was a simple way to "INSERT, DELETE, and REPLACE entries within a feed" via HTTP. That is, it would be nice to edit web feeds by simply specifying an URL and the appropriate parameters.

Now I'll admit I'm either misunderstanding what Udell is saying, or he has missed something very obvious to hardcore programmers like myself. If you want to add/insert, delete or edit/ replace an XML web feed entry and don't want to use the typical blogging client interface, you have an option.

I would write a PHP or Perl script that parses an XML feed, then check the incoming URL's parameter string to determine what operation to perform. However, it would be nice if someone would standardize the behaviour of such web feed editing operations, just like SQL (Standard Query Language) was devised to standardize the behaviour and manipulation of standard databases. This standardization might actually be what Udell is aiming at.

I should point out that in Udell's article, he is partly echoing the words of Adam Bosworth, who also gave a keynote address at XML 2003. In particular, they both feel that the "scalable databases of the future" might be "more like the web" (i.e., using XML syndication formats) than traditional databases that are based on SQL and RDBMSes (Relational Database Management Systems).

Now while I think that this would be theoretically interesting, I believe that this may be a bad precedent, if not handled properly. Why? Because XML was never designed to be a compact format. In fact, the XML specification paper makes no bones about it being a verbose format. We have enough bloated software out on the market already. Data should not also follow along.

As an example, I recently marked up an web server visitor log file and used the shortest XML tagnames I could without being overly cryptic. The XML version of the log file was 4 times the size of the original. For low-volume websites like my hub site, that's okay. It's not good for highly-trafficked sites.

Similarly, for small web feeds, that may be okay, but not for large volumes of content. Also, while the inherent structure of a web feed might be XML/RSS or XML/Atom, very few feed publishers actually store the content in XML. The source content tends to be stored in traditional databases. So I question the need for an HTTP-based method to read/write web feeds.

Furthermore, XML is not a "normalized" form, which is a sin in database theory because of inefficiency of storage. That is, XML by it's very nature has a redundancy of field tags, and thus eats up space. While some data can and should be stored as XML, such as an actual published RSS feed, some data should not - such as the source content that is used to publish an RSS feed.

On the other hand, the idea of an HTTP-based method for updating an RSS feed is a brilliant idea, providing that such a method translates into updating the source content in a traditional database and not in XML. So when a source database is updated, this will be reflected in the web feed that end users see. But aside from RSS readers that download web feed content in RSS format, feed content should be stored in a traditional (normalized) database. (That's just my opinion as a 28-yr veteran programmer.)

What I actually find most fascinating about the article is that Udell thinks that the RSS format won over Atom in the "first round" of the "squabbling within the already fragmented world of lightweight XML syndication," but feels that the Atom API (Application Programmer Interface) "will win the next one".

I unfortunately have to agree with him on that one. I think that RSS is a better format, but Atom proponents have a lot of pull in the Internet technologies development world. That includes one of the original authors of the XML specification. RSS needs an API like Atom has. (Am I missing something? I'm pretty sure RSS doesn't have one.) RSS also needs to become a W3C standard like Atom 1.0 has become. Either that or the two formats need to merge into a single version that is a standard and has an API.

Regardless of my disagreement with some of the things that Jon Udell is saying, his article is a must-read if you plan to develop in RSS/Atom. There are some excellent ideas in it.

Links: Jon Udell's blog, The Two-Way Data Web

(c) Copyright: 2005-present, Raj Kumar Dash, http://www.chameleonintegration.com