Sam continues to provide an excellent perspective on moving RSS forward:
I really would like to see the day where compatibility to the spec was as important as "works with the current version of the software provided by the spec author"
... as a contributor to a SOAP toolkit, I don't want SOAP to be defined in this way.
Meanwhile, here is the perspective of an author of another aggregator . [ Sam Ruby ]
Thanks Sam, especially for that pointer to Aggie .
In Radio, the path of least resistance at this moment is to clone the RSS writer and add in experimental tags. The better way (in my view) is to replace the RSS writer with a modularized writer that compartmentalizes experimentation according to the RSS 1.0 spec which was designed for that purpose. A Radio hacker is free to do either or both of those things. I've done the first, and plan to do the second unless (hopefully) somebody else gets there first.
In either case, it seems to me, the gating factor is whether and how the UI exposes custom tag creation to the user, a la the Categories feature in Radio now, and whether and how the UI enables the user of the aggregator to work with extended metadata.
Coming back to the lawyers-and-asbestos angle, it's worth noting that the ability to solve the problem already exists. The .92 spec supports categories; categories can be created in the UI; categories can be routed as complete XML feeds. Although I completely agree with the points being made about extensibility and namespaces, I don't think these issues are preventing lawyers from today organizing their communication around topical feeds. Rather, I think what's stopping them is Sam's observation about the general lack of appreciation for the most basic uses of RSS.
There's a mom-and-apple-pie aspect to metadata collection. Everybody's for it -- at least insofar as they imagine a neatly-tagged semantic web made available for them to use. When they realize it's their job to do all that neat tagging, though, enthusiasm (rightly) wanes. If we had lots of people using software that made metadata collection seem natural and effortless, I don't think it'd be hard to sort out issues of extensibility and namespace collisions. Those would be good problems to have, in other words.
Former URL: http://weblog.infoworld.com/udell/2002/05/20.html#a257