Dave's resuming a serious pitch for what he calls the World Outline. While we don't know exactly where he's going with the idea, it's more interesting then you might think on the first cut. Or at least what I've thought of the idea is more interesting then you might think.
He calls it "parallel to the HTML web, a new way of webbing." I don't know that I'd say parallel to the web... 'course, I'm not Dave... because that often gets translated in people's minds to "serving the same purpose as the web". In my understanding, the "new way of webbing" part is much more interesting.
I think Sjoerd is starting to see it. In a way, OPML is a further simplification of XML, in a way that sacrifices very little of the power, but makes it much easier to produce and consume. What's interesting is how much stuff can be boiled down to an outline, if you're willing to cut a few corners.
We've already seen outlines that edit Manila sites, which is not an application that may leap to your imagination. And we've seen outlines that are directories. (Here's the OPML to prove it's an outline.) We've seen RSS outlines.
The 'mind-bomb' aspect of this is that you have to clear away some rather ingrained notions about computing. Clear the slate for a moment. Try this on for size: A configuration dialog box that's an outline, instead of a box. Edit the parameters to your desire. Need help? Click the node and expand it; context help so easy to use and program that people might actually use it (and program it!). You've also sort of seen this, too, if you're using Radio Userland: Your prefs page is implemented as an outline, rendered to HTML. Why not use it as an outline directly? (This may seem wierd, but it's not half bad.)
You can store your email in an outline. ("Why would I want to do that?" Bear with me.) Most good newsgroup readers are basically outlines. Uncounted thousands of specialized applications here and there can be built out of outlines. (A biggie you've probably heard of is the Registry Editor in Windows. That's just an outliner.) You can do whatever it is Dave is hinting out with outlines.
Some other interesting tidbits: Your undo history is an outline. (I've only ever seen Adobe Photoshop do anything with that.) If you've ever undone twenty things, typed one key, and then wished you could "undo" that action and get the old sequence back, you've wished your undo was an outline, instead of a straight line backwards and forwards. (An outliner app could use that, because it's already got the UI for manipulating outlines.) Your browsing history on the web is an outline, one that Google would probably love to get their hands on. Your help system is an outline. Your bookmarks file is an outline. Your network is an outline.
In fact, there's even more, but this is probably far out enough. It's sufficiently interesting that one of my two current hobby projects is a Python-based outliner. (Wherein I've learned that modern widget sets actively fight good outlining.) (The other is a game that will never see the light of day, but is wonderfully fun to design.)
It will be interesting to see where this goes, because IMHO the most interesting benefits are the intangibles that aren't flashy, and don't attract people. They just sneak up on you, until one day about six months in to using the tool, you don't know how you got on without it. You get:
Uniformity of interface: Not all nodetypes can reasonably support all operations, but you get some powerful operations expressed in these things simply, like indenting, dedenting, hoisting, popping off a new window, and all kinds of other things that are really, really useful. And everything, for the most part, is text. Editting XML is the same basic skill as reading your RSS feed is the same basic skill as composing an email. There's probably something to be said for that. (Copy and paste becomes quite powerful.)
Exponential benefit: As the number of nodetypes increases, the power feeds back into themselves, as they can work in combination. Again, the power sneaks up on you, until one day you're instant-messaging someone a directory node with an embedded link to a Manila site where the discussion board has an embedded link to an RSS file with an active link to a new Wiki site, and you realize there's ten reasons you couldn't have done that last year. (All in the same program, too.)
Nodes carry the verbs: The previous scenario is cooler then it may seem at first because the outliner understands those objects. Like the RSS feed? Right click, select "Subscribe", and now Radio Userland adds it to your subscribtion. Post on the discussion? No prob. Add the directory to your own site? Copy and paste. Compare that with an HTML link, which is by comparision a dead entity. Right click on this to your heart's content, but I guarentee you won't see "Add subscription to this RSS file" in the resulting menu: http://www.jerf.org/irights/rss.xml .
Programming's a little easier: Making something into a nodetype provides a basic interface across the nodetypes. Applications get the benefit of working across all the nodetypes. For instance, the spellchecker works in everything: e-mail, web, directories, everything. Link checkers, too. Similar applications may abound. Stick your email in an outline, and get all these applications for free. Have a beef with the representation of the email? Fix it, and the benefits can propogate to all nodetypes. (Goodness knows I've wished the Windows Registry Editor would benefit from some of this...)
Multiple views on the same data is easy: Take this in the concrete: I run the Community Tools directory, as much as possible, as an OPML document aggregating lots of little OPML documents, each representing a Tool. The "official" directory is just one particular view of the resources. Anybody else can take those pieces and assemble another view. I mentioned the network above; you can have a flat view, or a view organized by function, or by the department the computer's owner works in, or by room, and each of those is a view on the fundamental "computer resource" node. (Of course, we'll need apps and programming techniques to make this easy. We've seen this elsewhere, of course, but it's never been easy enough to bake into everything.)
This stuff doesn't come for free.
I think Radio is going to need some more UI. For any but the trivial nodetypes already implemented, we're going to want to be able to manipulate the attributes of a given node conveniently.
The user needs a slightly more complicated mental model. One of the cool aspects of this idea is that the slightly more complicated model adds far more power then you'd otherwise think, but it's still more complicated. Making it easy will be tough... what's new? (At least you can slide into it, like Dave said. The learning curve is quite flat.)
Of course this isn't good for all applications; there will be at least a few ill-considered attempt to map something to nodetypes that shouldn't have been. That doesn't disprove the idea, though.
In the end, is this a good idea? Frankly, nobody really knows, and that's what I think this boils down to. I think it's worth a try.
Never underestimate the power of reducing friction; even small changes towards the easy end of usability can result in massive increases in effective power, because of the inverse relationship. (Ex: .1 and .01 are pretty close together, but 1/.1 and 1/.01 are not.)
(You get a kick-ass OPML homepage out of the deal; in a way, this is what I look forward to the most. Details deliberately vague on this point. Check back in five years to see if this was right.)