intertwingly

It’s just data

dc:creator

Items in my comments.rss2 feed now have dc:creator information.  This should help NewsGator users.

You're welcome, Greg.  ;-)


Future of RSS

Based on Dave's question and Tim's criticisms, I've gang-blogged my thoughts on where RSS has been and where it is going.

When I was done, I wasn't sure whether I had an essay or a number of blog entries, so I thought I would experiment with the format.


Ghosts of RSS past

To explore the future, one needs to understand the past.

In the beginning, items in RSS 0.90 had only titles and links.  Items in today's RSS feed for scripting.com has neither.  Where's the continuity in that?

The answer to this question is that RSS 2.0's primary author, Dave Winer, has consistently demonstrated that he fundamentally understands that data outlives code.  Not be a little, but by a lot.  And not sometimes, but always.

Case in point: consider that while scripting.com's RSS feed has neither a  title nor a link, every aggregator out there supports both title and link.  And will for the foreseeable future.

Why guid instead of link?  It turns out that link has been used rather ambiguously over time.  In some feeds the link points to the article the item discusses.  On others it points to the item itself.  Which is right?

There are plenty of other areas of ambiguity.  Can description contain HTML?  If it can contain HTML, can any hypertext links contained therein be relative?  If they can be relative, what should they be relative too?

How do you correct "bad" link tags and descriptions?  You don't.  They will exist forever.  The best you can do is to provide a more constrained, predictable, and reliable alternative.

I propose that hypertext links inside of xhtml:body can be relative.  And that they are be evaluated relative to the URL of the RSS feed itself (as opposed to, say, the value of the /rss/channel/link element).  Towards that end, I'm hereby publicly challenging Don Box to work with me to help formally document the usage of the xhtml:body element in the context of an RSS 2.0 feed.  Others that wish to participate are, of course, welcome to do so


RSS: it's not just for syndication anymore

RSS 2.0 is a great format for syndication.  It also is a great format for archiving.  It is the basis for a comment API.  It is the basis for the RESTLog API .  It would make a great weblog ping API.  Etc.

What makes it great for all these uses is that it is extendable

Given all this, what more could be desired?

I'll tell you what.  It would be nice if RSS items were explicitly designed to be embeddable.  By that, I mean able to be included inside of other formats which are designed to be extensible in exactly the manner that RSS 2.0 is.  Quid pro quo.

What does this require?  It requires the ability to place RSS item information into a namespace.  This does not mean that all of the previous RSS feeds out there suddenly become invalid.  To the contrary, it just means that a namespace needs to be identified and that there be general agreement that elements in this namespace in RSS feeds are to be interpreted identically to the way that unqualified elements are today.

In short, all feeds which are valid today will continue to be valid.  Some feeds which were not previously considered valid would now also be valid under this proposal.

Who will use this namespace?  When used strictly for syndication, I'll readily admit that not many will at first.  Perhaps some of us who have multiple feeds will explore using this namespace in one of them.  That alone will be enough to spur authors of RSS parsers and aggregators to support the namespace.

The support will typically not require much in terms of lines of code.  Some aggregators will not need to change at all.

So, why is this important?  Why all the fuss?  Simple.  I foresee a future in which there are many, many more applications of RSS than there are today.  Some will be standalone.  Some will be embedded.  It is my hope that by making this simple change today, the future users of such parsers and aggregators will be pleasantly surprised to find that they are already enabled


RSS namespace proposal

Here's the set of changes I would propose to RSS 2.0:



= = =

Summary: At a minimum, I'd like to see an optional namespace be identified for items.  Ideally, this would work for channels too.  Nothing more need be done.


Control freaks

Don and Keith (who has a broken permalink) call me to task on my If you ever are in a position where you can control both ends of the wire... There are much better protocols than SOAP statement.  This statement is merely a device I use to get to the heart of the issue quickly.

The primary purpose of this statement is to deflate arguments like this one.  Read the entire thread to see how well it works.

It is also about setting expectations... for example: round tripping is not always 100%.  There are a concessions one must make in order to achieve true platform and language neutrality.

But mostly it is to make the point that you rarely control both ends of the wire as much as you might think.  Systems are fractal.  Even if two relatively adjacent parts are developed in the same language on the same platform by the same company, if there are two teams involved and the interface is viewed as a contract, then it makes sense to view this interface as an fungible.


Chandler 0.1 available

Mitch Kapor: We are focusing first on architectural issues, not end-user features, yet there are some interesting things to look at in this release. In particular, the outlines of the Chandler peer-to-peer sharing framework are visible.


Better blog distribution, part 1 -- the assumptions

Dan Sugalski: I loathe the current "poll for RSS" scheme of seeing when blogs update, along with an utter lack of notification for things like trackback links and comment pings. What I'm proposing is an NNTP-style system with a set of loosely connected server systems that take notifications from the end-blogs and pass them around to whoever's watching, with the notifications ultimately hitting clients connected to those servers waiting for notifications of changes.