RSS' flexibility: A harbinger of challenges ahead for tool makers?

RSS' flexibility: A harbinger of challenges ahead for tool makers?

Summary: 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).

SHARE:
TOPICS: Browser
0

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?

RSS feeds, as I learned in my exercise, are unpredictable enough that if you're stringing together software components that rely on them, you may have to fiddle with what's inside the sheath. As uninviting as that sounds, the components should eventually catch-up to the shrink-wrapped software in their ability to deal with variable feed formats. But, bubbling that flexibility up into the user interfaces of development tools designed to demystify programming for non-programmers will prove to be very challenging for the tool makers. It makes me wonder where else, beyond RSS, such flexibility in data formatting is manifesting itself and what that means for the future of point-and-click programming.

All this said, the two observations that I had the most fun making were in this part of the story:

With Web syndication, the consumption side is bearing the burden of the choices being made on supply side. In other words, control is shifting from away from vendors to the content publishers. Note that this phenomenon is the reverse of the direction that the Web took. (Given the popularity of Internet Explorer and how many sites don't work in Firefox, hindsight demonstrates how the supply-side adjusted to the consumption side.)

and (on the issue of the optional use of RSS' title tag):

[Dave Winer's] blog is just a stream of consciousness. When you're thinking about something (anything), do you give it a title first? Neither does Winer -- nor should he have to.

Tell me what you think.

Topic: Browser

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

0 comments
Log in or register to start the discussion