A key aspect I don’t think quite came across in Jim’s excellent post is that these ‘layers of directories’ and ‘rivers and oceans of content’ do not have to be still nor static – they can be truly dynamic and liquid structures.
“People are now consciously creating and sharing reading lists and OPML directories of sites of interest. But more important, as OPML management tools proliferate people are assembling their own directories of directories. That is, they are assembling for themselves carefully selected groups of web editors, who are themselves creating and maintaining directories, in the Yahoo fashion. And all this is being done in an open and unpaid fashion–sometimes as a completely voluntary initiative, and sometimes supported by ads.
And every person who has a site can in turn subscribe to OPML outlines which in turn reference layers upon layers of directories, maintained by layers and layers of editors, pointing to vast, folk-structured rivers and oceans of content. And all made manageable by easily expandible, scannable, and searchable OPML directories.”
This point relates to one criticism of OPML I’m hearing on a regular basis now is the remark that ‘all this can be done in HTML’. Here is a typical example (in the comments to Jim’s post) that pretty much sums up the objection:
“But what you see on Dave’s web site is HTML [in reference to Dave Winer’s Directoryroll]. The actual functionality needed for what you are describing is already with us in HTML and the web browser. Even this page contains a directory of links, which could easily link to other people’s lists and directories of links. OPML may be an aid to imagination, it’s easier to think out of the box with new toys (or rather reappraise old tricks like Gopher and Yahoo! directories), but there’s absolutely no need to create a whole new stack of formats and tools. I could just as easily subscribe to the links on this page as the links in an OPML file you provide. The only real difference being that I’d need a special tool to view the OPML, whereas the HTML links are usable in the browser. We already have this technology, let’s move existing tools forward, rather than being led down a cul-de-sac.”
There is something that is hard to explain with OPML. The difficulty is in its distributed nature. The above objection reminds me of some of the early pushback to RSS. It goes something like this: “Why have RSS when we can go and visit a website?”. Well, I can go and visit the website, sure, but what if I want the website to come to me? And what if I want to start ‘doing stuff’ with it like dynamically republish the website’s content elsewhere, or recombine it with other stuff, or store it, index it and run algorithms against it, or create new interfaces into it. HTML breaks down at the first hurdle here (unless you enjoy the business of screenscraping and that’s whole other nasty kettle of fish). And hey, if you don’t want all this syndication/remixing to happen to your website, well, then don’t RSS it. But you’ll soon become irrelevant if you make that choice.
You remember what is was like. Until you had your first play of a feedreader it was really is hard to understand the benefits of RSS. It was an ‘aha moment’, for me at least. It one of those things you just had to try to ‘get it’. Like sex I suppose. It doesn’t matter how hard I try, if you are a virgin I won’t be able to get across to you just how good it is! (although that would be more like a ;ahahahaaha moment’) You just have to try it out – you’ll see what I mean.
OPML is similar to RSS but different. It is similar to RSS in that it enables these distributed and syndicated scenarios to be played out really easily.
But OPML is different to RSS in that it allows structure to be distributed & syndicated and it allows this to be done in an entirely dynamic manner. I just can’t do this in HTML (I can’t do this with RSS either). What you see when you visit Dave’s Directoryroll is a rendition of a structure – the OPML files – at that moment in time. If the OPML file(s) changes, so does the structure (and so does HTML page). There may be multiple OPML files being referred in his Directory and each of these may be independently managed by many people and machines across the network. This is the point Jim made so eloquently. The HTML you see is one manifestation of this distributed structure – on a webpage at that specific url. Other manifestations are happening at other webpages (combined with other OPML files) and within other tools.
The commenter (‘Danny’, but he doesn’t say which?) sees these other tools as a weakness. On the contrary, I see this as a strength, not weakness. You can render all this in HTML/DHTML/AJAX/AFLAX if you want, but you can also do it within specialized tools made for doing a particular job really well. That’s what RSS readers are – specialized tools – and they happen to use OPML at a fundamental level to do their magic. I haven’t heard anyone objecting to RSS readers because they separate tool to web browsers, not for a long while at least. You can do it in browser if you *want* to, but you don’t *have* to.