Partager via

OPML - can do it in browser if you *want*, but you don't *have* to.

  • Article

 Lisa is doing a create job of trawling the net for some OPML gems. If you are interested at all in OPML, you need to subscribe to her feed.

Tonight Lisa pointed out this post by Jim Moore:

"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."

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.

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.

Tags: opml, rss syndication

Comments

  • Anonymous
    November 28, 2005
    The power in both RSS and OPML lies in its machine readability. Someone's custom AJAX presentation of information is nice to use for humans, but isn't standardized so that my computer can read and manipulate it without having to write a custom parser. Put the data into standard containers and interchange formats (which is what RSS and OPML are).

    To me, these formats are getting confused in how people see them. They are NOT destination formats (HTML/DHTML/etc). They formats for machines to move around and manipulate. And, in pretty much ALL cases (unless you're seeing XML tags when you read your feeds), they get turned into a destination format by the time you read them.

    Just note one of your first reactions to my OPML sampler. You wanted to push your OPML file in and get an RSS feed back out. Why? Because you wanted to use the data in ways that my simple HTML presentation didn't allow. And, these data formats are standardized (enough) to allow machines to read and manipulate them.
  • Anonymous
    November 29, 2005
    J Wynia, yes, this is a great distinction to make.
  • Anonymous
    December 01, 2005
    This Danny!

    The format is not the user interface or application.

    "Why have RSS when we can go and visit a website?" - nope, that's not the analogy I'm making. RSS in that sense is both a format and and informally-defined polling protocol and a bunch of applications. Right now it wouldn't be a stretch to have RSS/Atom done as (X)HTML, but back when Netscape came up with the stuff RDF/XML was considerably more suitable.

    Think MVC - the format is effectively a View, the same Model (linked lists, hierarchies etc) can be expressed in OPML, HTML, arbitrary XML etc.

    The same is true with OPML, but we're not in the same historical position as we were with RSS. We don't have to use a new format, HTML is now plenty good enough to carry the data. If the "destination format" can be the same as the transport format, why not?

    You can't view OPML in a browser without jumping through hoops, so why not use a format which is directly compatible with the rest of the Web?

    Whatever the format, you could still use the same protocol and have applications with exactly the same functionality. HTML is certainly good enough for carry sets of links - that's how the Web works. OPML has trouble even with that right now, if you have to use converters from one app to another.

    HTML is not just about presentation (as the microformats folks keep reminding me ;-)






  • Anonymous
    June 08, 2009
    PingBack from http://insomniacuresite.info/story.php?id=4657