RSS’ flexibility

Folks, RSS is here to stay. Don’t think anyone is going to argue this. But sometimes frustrations arise ranging from specifications to getting something together simple enough that anyone can use it right out of the box.

This article from ZDNet addresses a number of issues and concerns from the RSS arena. While some of the points made here may be a little bit ‘alarmist’, I think the article covers a number of things that do need to be looked at.

After an attempting to marry Wiki software with my favorite RSS feeds, I went on a rant about how the optional nature of most of RSS 2.0’s XML tags shifts the burden of dealing with unpredictably formatted XML streams to RSS readers and RSS-reading software components (the consumption side).

Canned “reading” technology like that found in Firefox’s Live Bookmark feature does a pretty good job of adjusting to the different decisions being made by content publishers in their RSS feeds — a sign that the protocol’s flexibility shouldn’t be too difficult to manage when using shrink-wrapped software to consume the feeds. But what if you’re attempting to tap the promised power of point-and-click programming by stringing together off-the-shelf software components in a way that produces an XML-enabled application suited specifically your needs?

I keep hearing that bloatware will give way to this model — often in the context of workflow-oriented Web services — and that mere mortals will be able to turn out the sort of sophisticated applications that only hardcore prorammers are capable of today. It seems to me that those components will have to behave in a very predictable fashion in order for neophytes to start plugging them into each other. Consider the predictable results of plugging one end of an Ethernet cable into your computer and the other into a network hub. Imagine if every network was different and you had to fiddle with the way the twisted-pair wires inside the cable’s sheath were fastened to the RJ45 connector at the end?