0xDECAFBAD - Tag: opml

cheating on my "real" blog

2007-11-13T01:00:40+00:00

decafbad recaffeinated is what I'm so far calling the Tinderbox-built blog with which I'm cheating on both my OPML blog and my "real" blog. Come take a look, if you're so inclined to watch another of my experiments. (Update: It's recaffeinated, not recaffinated. I ar gud speler.)

OPML reading lists in FeedMagick2

2007-10-17T07:22:47+00:00

For anyone who's interested: I've been hacking a little bit on FeedMagick2 again, with the latest addition being an OPML reading list feed blender.

What's an OPML reading list? Basically, it's the same as as OPML export of a feed reader's subscription list - only rather than doing a one-time import into another program, the OPML is itself treated as a live feed. A feed reader that supports OPML reading lists will continually check the list for updates and sync RSS/Atom feed subscriptions with its contents, maybe in a special sub-folder.

Here's a quick demo:

The itch I mean to eventually scratch is to replace the front page of decafbad.com with a live updating aggregation of the stuff I create and capture daily on the web. It'll be basically a self-assembling tumblelog pulled from many different services across the web. It'll also replace the footer of accumulated crud I've got on this very blog - which I thought was a good idea at one point, but now consider NeatLikeDigitalWatches.

With that in mind, the next thing I plan to develop is an hAtom module or XSL transform. This will turn the blended feed into an XHTML page. Maybe someday, hAtomic will launch, and I'll have a nice pretty style for the page too. Some time after that, I might work up a module that stows away dated historical archives of the feed and pages. I have further plans and ideas, but I'm trying to focus on the itchy spots first so that I might actually get something done in this round of serial enthusiasm.

XoxoOutliner and further outline addressing adventures

2006-11-15T08:07:12+00:00

Revised the addressing code a bit, adding a few new kinds of addresses and getting ready to support sub-outline updates. That is, fetch a sub-branch of an outline and then later post a change to that sub-branch using the same address. Needs more thought - ie. what happens if things move between fetch and update? - but here are a few more samples:

First is a straight linear index counting down from the top of the outline:
- http://decafbad.com/2006/11/XoxoOutliner/outlines/README;index:4?format=xoxo
Second is a navigation of outline structure, alternating numbers and letters:
- http://decafbad.com/2006/11/XoxoOutliner/outlines/README;level:3c4?format=xoxo

That's all for now. In my next round of enthusiasm, I may try stealing Tom Morris' Opath idea...

Archived Comments

Vincent D Murphy
2006-11-18T20:52:07

I think (and said as much on Tom Morris' site) that a fragment identifier would be a better solution, in which case Opath would be a fragment identifier syntax for OPML and XOXO. At least it would be the best solution from a REST/web architecture point of view..
l.m.orchard
2006-11-18T21:40:41

One reason I didn't use the #identifier URI syntax for suboutlines is because some gymnastics need to be done to get the hash through to the server from a browser. Otherwise, it gets treated as an in-page anchor. The semicolon syntax seems to work well for a set of path-segment parameters, and follows the standard (if I've read it correctly).

In either case, it works for me, and should be just fine in a REST context - the suboutline syntax here should always identify a single parent outline node as a resource, and will eventually work for GET / PUT / POST / DELETE.

Now I just need to implement a solution for the Lost Update Problem.
Michael Poremba
2008-09-18T23:45:56

Wondering if you ever completed your online outliner? Check out dynamiclist.com, a functioning but incomlete project I launched back in 2001. The editor is rich and works well. Been thinking of reviving now that all major browsers support the contentEditable tag.

Reading Lists, OPML, XOXO, Semantic Web, and Tools

2006-02-13T17:09:08+00:00

Listening to this podcast about OPML and Reading Lists and enjoying the various perspectives on RSS, OPML, and Semantic Web tech. It's also the first time I've heard Danny Ayers' voice, so that was pretty cool after having been a textual blog acquaintance for a few years now. As for the rest of the guys on the call, I'm not quite as familiar with all of them yet, but I'll be adding them to my Reading Lists shortly.

Apropos of this podcast, I've lately gotten a bit of a fresh take on the RSS/OPML versus XHTML versus Semantic Web tech merry-go-round. Here's the basic gist: Invest time into tools that solve problems first and formats that enable possibilities second, if you want to get any attention and subsequent help.

And then I say "tools", I don't mean a GraphViz construct that makes really cool charts for people willing to chase down and install the dependencies. No, I mean something like the OPML Editor. The OPML Editor comes in a single package, and you launch it from a single icon. The OPML Editor is a shitty piece of software that's nonetheless helping me achieve some practical goals that I've heretofore been vaguely stymied in reaching. The OPML Editor is making me think more favorably about OPML, despite OPML being a shitty format.

The utility of the OPML Editor is giving me the motivation to build filters and workarounds to transmute OPML into XOXO and RDF formats, but only when the need arises. I could also see putting an OPML-to-triples bridge in front of a semweb crawler or tool. And, there's no reason why outlines in the OPML Editor couldn't be rendered in XOXO and RDF formats by the tool itself, if there's something useful around to consume it.

On the other hand, I've done enough with RDF and XOXO to see the clear potential in both. With enough RDF data around, you can turn the whole wide web into a single massively networked database ripe for the querying thanks to a uniform data model and clear specs for representation of that model. With XOXO and microformats, you get a Sudoku-esque solution to providing both human and machine readable data in the same format and file, while sterring close to the inherent design principles of the web.

The problem with these formats, though, is that they open potential avenues but don't provide value until there's some foot traffic on the avenues. This is just establishing a world in which there can exist both chickens and eggs, but not doing much with respect to concrete instantiations of poultry. Now, to be fair, there have been efforts to make practical usage of RDF (see: MusicBrainz) and these are early days for microformats. But, I think a lot more effort needs to be given toward making useful, personally rewarding tools - and less effort given toward expressing awe toward the potentials given by formats and models. You can have both, but you've got to pick one to start with.

And, the reason you need to make tools first that use formats second is attention. (That's been a buzzword lately, hasn't it?) You need attention if you want adoption and help. And, you can get attention - and subsequent help - by scratching someone's itch.

Now, some people's itches are scratched by the fun of abstract symbol manipulation and the perception of elegance. Others' itches are scratched by getting work done, like writing or organizing thoughts or expanding awareness of more information sources. Personally, I've got itches of both of these varieties. The problem is that there are many fewer people with itches in that first category. And, no offense to anyone, that seems to be the bulk of the RDF and XOXO fanbase at the moment. For the second category, even if things are shitty, smoke a bit and catch on fire - as long as some work gets done at the end of the day, there's a lot of tolerance to go around and a lot of motivation to pitch in to improve the situation.

At the end of the day, I firmly believe that ATOM, RDF, and XHTML-based microformats trounce OPML, RSS, and the like in terms of clear definition, affordance in manipulation, and technical elegance. But, OPML and RSS are still winning in the world because the tools using these formats are scratching some damn annoying itches. And, though towers built atop shitty tools and formats seem Jenga-shaky, somehow they never quite come crashing down. Maybe they will come crashing down someday, but we seem to be getting work done in the meantime.

So, to wrap up: My take on this whole mess is that your format will gain adoption to the degree that the tools producing it help people get work done. I can't find tools today for RDF and XOXO that are as rewardingly useful as the OPML Editor has become. When that happens, the story may change.

Archived Comments

Edward Vielmetti
2006-02-14T02:32:49

There's a lot to be said for rough consensus and running code, and there's a lot more running code that speaks OPML than there is that speaks XOXO or RDF. You can just plain sit down and get work done and not have to entangle yourself in a microstandards battle. There's a certain appeal to that.
phil jones
2006-02-14T03:03:10

Same as it ever was :

http://www.laputan.org/gabriel/worse-is-better.html

(scroll down to section 2.1)
Phil Wilson
2006-02-21T20:39:35

I know they're very different things, but is there any particular part of the OPML Editor that doesn't exist, say, in something like NVU, or a stripped-down TinyMCE?

Don't Pee in the Potato Chips

2006-01-28T07:02:15+00:00

So, I've expressed some renewed interest in tinkering around with the code behind the OPML Editor and NewsRiver. Well, it needs to be said that there are some strings attached to playing in this field: That is, these are Dave Winer's potato chips I'm enjoying.

And, well, when you're taking chips from another another guy's lunchpail, it's customary to at least be nice to the guy and be gracious about the sharing. Granted, when I'm done, there could end up being more potato chips left in the bag than when I found it—that's the nature of this sort of sharing, after all. But the bag, nonetheless, was brought to the table by Dave.

Although I've tried to bow out of it over the past few years, I have historically been found amongst the crowd who've been known to take pokes at Dave when it affords a run of chuckles or guffaws. Sometimes, this has been in the pursuit of making a technical point or two in dramatic fashion—but often this has just been done toward the goals of playground-level politics and tit-for-tat.

Well, this crap doesn't suit me. Or at least, I don't want to be suited for it. You see, I really just care about being friendly, working on decent code—and besides, my Winer Number is right around Mu.

Although I've been witness to many clashes of ego involving the man with others of strong ego, I've never actually been the personal victim of any slight from Mr. Winer that I care to count or remember. It's been fashionable to poke at him, but my goal is to keep my ego at a calm distance from most things in life and I've not got any personal gripes with Dave Winer.

On the contrary, when I look at my career over the last few years, I see plain evidence that I've benefitted well from the man's influence—even if indirectly from his work. I've successfully profited from implementations of XML-RPC and RSS. I've managed to write my first book thanks to things I first picked up from him. And, I've learned a lot in pursuing fractional horsepower HTTP servers.

Dave writes shitty software and evangelizes shitty ideas. And, since the turn of the century or so, I've adopted and improvised upon many of them for fun and profit. Thus, while I don't want to be on any "side" or in any "camp" or be a mindless fan or follower of anyone or anything—I do feel a need to at least be nice to Dave Winer while I'm sharing his potato chips.

So, Dave? I'm sorry I've pissed in the bag of chips a few times. Maybe we can just call those salt and vinegar and let someone else eat 'em. In the meantime, I might make a run to the party store for some dip or something.

Archived Comments

Brad Neuberg
2006-01-30T10:54:25

Do you have a online demo for the OPML Editor you mentioned ?

Ancient code drifting down the newsRiver

2006-01-28T06:08:57+00:00

So, while working through some writing blockages last weekend, I started doing some hacking on Dave Winer's newsRiver running on the OPML Editor platform. (Oh, and it is a platform, maybe more so than even emacs—don't let the moniker 'editor' fool you.)

Here's the thing: It was a lot of addictive fun, and it takes me back to the love/hate thing I had with Radio, back toward the first days of this blog. This Frontier / Radio / OPML Editor environment is undeniably satisfying for me to work in. It's like potato chips: Jump to an outline here, tweak some code there, mangle an outline node up there, reload a browser page, watch things go—lots of moments of instant gratification all building incrementally atop one another.

In one package—which reminds me a lot of Squeak—the OPML Editor bundles a crazy amount of integrated machinery for both Windows and Mac OS X:

UserTalk, a very capable scripting language
An IDE based on outlining, somewhat like Python's syntactic indentation
Persistent on-disk hierarchical hashtables (aka the Object Database)
Code and data all live in the same object database
A web server and a host of other networking code—including Jabber messaging, although I can't attest to its freshness.
Blog editing and no-effort external web hosting file synch
Hot patching and easy upgrades that most other software packages dream of
Years and years and years of (mostly) working code with datestamped change notes and living history.

And the thing is? This was the state of the art for Radio back in 2002—and earlier than that even for Frontier. Fast forward from then till today, and you'll find that Frontier is now Open Source—with many of the same sorts of warts Mozilla's open source release helpfully revealed back in 1997. (Some hero needs to come along and port this beast to Linux! Good luck!) And now, much of the guts of Radio are released as the OPML Editor.

In a lot of ways, this whole family of apps built on this common ancestry of code is really shitty software. Kind of like all that code on the Qeng Ho from Vernor Vinge's A Deepness in the Sky. This stuff crashes and sets itself on fire a lot, but then again it's amazing to see just how many wheels have been reinvented and re-reinvented since 2002 (and before) when I fire up this code today.

And now, it looks like the embers are stirring for this thing again. There's been a lot of time for a lot of angst to fade from a lot of places, and it looks like there's a new crop of fresh people rediscovering this stuff.

So, anyway, I like these potato chips. I think I want to start munching on them again, as time permits. Oh, and while I'm talking about potato chips—I have to say, don't pee in the potato chips and be nice to the guy holding the bag.

Archived Comments

Robert Brook
2006-01-28T15:03:50

Serious question: why not use Squeak?
l.m.orchard
2006-01-28T16:01:26

Robert: Short answer is that I saw Radio first for the RSS aggregator and blogging support, started hacking on that, and got sucked into other aspects of it along the way.

For Squeak, I saw some fun colorful things and kind of got the gist of the environment, but never got hooked on any daily uses of it after a weekend or two of playing. So, it fell into my "Learn Smalltalk" todo item that keeps getting pushed down the list by other things. That item's still on my list, though, and I mean to get to it someday...
Danny
2006-01-28T16:07:44

From what I've seen and read there are loads of good ideas in that platform, but there are two things I personally find extremely offputting : the pervading sense of Not Invented Here, and the sheer age (in the negative sense) of the stuff.

Now the code's been open sourced, maybe there's a chance of the tastier crisps (UK localization) catching up and being integrated with the rest of the world. Ok, very IMHO but : swap US-ASCII for utf-8, XML-RPC for doc/literal XML, RSS 2.0 for Atom, Object Database for triplestore, Python for UserTalk, outliner for modern IDE (although actually the outliner UI is probably one bit that might be worth preserving as-is) etc.

Well, ok, maybe it is a bit much to expect. Maybe a maximally interoperable version of the Frontier approach could be recreated (without reinvention) by plugging together various existing open source libs..?

For now I guess I'll have to make do with Web as Platform (and/or Squeak) ;-)
l.m.orchard
2006-01-28T16:28:59

Danny: Yeah, I agree with a lot of those points, and they fall into the 'hate' side of the 'love/hate' thing for me. (Well, more like 'strong distaste' than 'hate' anyway).

And I've realized that, since drifting away from Radio/Frontier, I've been recapturing it in various forms using tech like Python, triple-stores, mini-HTTP servers, and the like. And although these things have felt 'healtier' in a non-NIH, bigger community, more loosely coupled way... it's still a satisfying experience (like potato chips) to find it all buttoned up in one integrated package that works on most of the platforms I care about.

It's still kind of a writing-with-my-wrong-hand kind of pain in the butt to get all the loose coupled stuff working sometimes. And many times, there are very good reasons for thing being hard and lots of things need minding. Like, XML-RPC style web services versus REST:

REST is a cleaner, more web-natural approach—but sometimes it takes a lot of thoughtful meta-tinkering where that XML-RPC stuff would've had you on the road hours ago. Of course, years from now, the XML-RPC stuff might smell a bit while the REST stuff will have stayed solid and revealed further unexpected benefits... but bah. They both have their place.

It's a lot like baked versus fried. Anyway, rambling now.
Danny
2006-01-28T16:57:00

"It’s still kind of a writing-with-my-wrong-hand kind of pain in the butt to get all the loose coupled stuff working sometimes." Nicely put, yup. Bit of a challenge. Coincidentally, yesterday the idea of "Semantic Web in a Box" came up - maybe the place to start would be "Web in a Box"...
arbitrage betting
2011-06-23T02:16:57

Nice points there. I agree with you. Those steps dated in the past are still very useful and helpful until today. We just need to be careful which ones to use. Munch more potato chips! Cheers!

Use del.icio.us to build & share Reading Lists?

2006-01-19T20:08:37+00:00

As far as I know, the most popular link managment tool is del.icio.us, a tool I love for its power and simplicity. del.icio.us allow you to export all your links in RSS which is cool. So, I wrote a quick and dirty PHP script that converts this RSS export to an OPML list (see at the end of this post).

Source: vrypan|net|log » del.icio.us as feed manager

I haven't had much chance to dig into Dave Winer's new newsRiver tool for the OPML Editor, but I've at least installed it and nodded at it. It's not much more than the aggregator I used to use in Radio—but the big difference is the promise of fresh new development.

And yeah, I know, I groused about OPML versus XOXO not more than a few months ago. But, although I still would prefer cool things being done in XOXO, Reading Lists (in OPML) would appear to be one way to get the stratified River of News that I'm looking for. That is, a Reading List can be a news strata in an aggregator.

But, beyond my prioritized folders in NetNewsWire, a Reading List in OPML can be serialized and shared and subscribed. Yeah, aggregators can already import and export OPML subscription lists—but I've never seen this feature automated by subscription until now. This is the difference between an MP3 download and a podcast.

And, if you check out the above-quoted blog post, these could even be collaboratively maintained by way of del.icio.us and a simple RSS-to-OPML gateway service. I've got to say, this could be one of the niftiest bits of mojo to hit syndication and aggregation tech in awhile.

Subscriptions are attention, but what about blogrolls?

2005-11-27T21:29:53+00:00

But today, for my rss feeds importing and exporting needs, OPML far outshines xoxo.

Yes, there are 6 XOXO outlines on my front page. There are six lists. But I don’t have an easy way to import one of those XOXO outlines in my FeedDemon application in order to receive the latest blog items from those blogs that I link to. If there IS an easy way to do it, please enlighten me.

Source: XOXO vs. OPML at DLTQ.org

Ah hah. Here's a use case where I agree OPML has undeniably become king: Exporting and importing feed aggregator subscriptions.

Because Radio UserLand was the first aggregator to really take off—and because OPML is Radio's lingua franca, any new aggregators have needed to speak OPML to facilitate migration. It grew from there, with nearly every aggregator supporting some basic form of OPML import/export for subscription lists. OPML has won the "feed subscription list format war" before there was ever a notion that there might be such a war.

Now, I'm woefully behind on all the buzz connecting OPML with attention. But, my impression so far is that people want to share their subscription list, exported from their aggregator of choice. That comes out as OPML. So then, the reasoning is that because aggregators produce OPML, and aggregators are powerful attention managers, OPML is the lingua franca of attention. Is this about right?

I guess where I go from there is with this: My aggregator's OPML export is private data for interchange between my other aggregators. Today, I'm about as comfortable with sharing my OPML with you as I am sharing QIF files exported from my bank account. Sure, it's an easy export process, but it's not meant for you.

In my OPML, I've got subscriptions that I've paid for, that I've password protected, and that give me details derived from my server logs. I don't want to share that, at least not directly. I've been asked for my OPML by a few people so far, and every time, I need to dig through it and be sure I'm not giving away any secrets. Maybe this is where I'm a bit confused about the attention hype.

You see, what I do want to share is called a blogroll. Blogrolls are public declarations of attention, published on blogs.

Since revamping this blog, I haven't yet gotten around to throwing a proper blogroll together, but I'm planning on it. And, when I do share it, it'll be in HTML list form. And when I build it, it may start as an OPML export from my aggregator, but I'll have to spend some time weeding through it.

I guess I don't have a clear picture here yet, but directly shipping around exports from my aggregator subscriptions gives me the willies. And further, basing anything big on OPML gives me the willies too.

Nowadays, sharing things on the web feels like XHTML and microformats to me. OPML for interchange between aggregators is one thing—but on the web at large, sinking deeper roots into OPML and the whole Rube Goldberg array of machinery following behind it feels like a backward step to me.

Maybe microformats are the new XML-geekery, but I don't want a new, "cleaner" XML format—I just want to more cleverly use the format that everyone's been using to share outlines and declarations of attention in blogs.

Archived Comments

Aristotle Pagaltzis
2005-11-27T21:37:59
Check out Uche Ogbuji's pertinent posts:
Adam Lindsay
2005-11-28T11:48:40

My aggregator’s OPML export is private data for interchange between my other aggregators.

See, that's where you've lost me. Regardless of OPML's suckiness (yes, I've gazed on it, first hand), export/import interchange formats are precisely the sort of thing to be open standards. I spent many of the prime years of my life working on MPEG, and that, if anything, was my take-home message. The interchange/glue formats are precisely what need to be scrutinised and kept in public view.

Is OPML good for anything else? Not really. Should it be promoted for all one's outlining needs? Not really. Does XOXO have an easy time of gaining mindshare, considering most people's miniscule outlining needs? Not really.

Half-hearted Gopher NG

2005-10-03T22:34:43+00:00

So, yeah, I had some spare time at lunch and I started expanding my little XOXO linked outlines thing into a more fully-fledged Gopher NG with OPML support. But, I'm not sure if I'll really do much more with it. It started on a lark, really. But after awhile, I realized that I don't have any use for it other than as an interesting exercise. Moving along...

Web directories with XOXO and XSL

2005-10-03T03:50:17+00:00

Now, in my previous post, I'd mentioned that I might have some ideas to "put up" in response to this recent OPML and web directories kerfluffle. Here's my general idea:

How about trying XOXO, the rel attribute on HTML links, and the subsection link type—all with a bit of XSL to make it work?

Here's some working data and code:

Here's the end result, a simple web directory.

Here are some clues as to what the above does:

This directory started with this top-level outline. View source on this page, notice the "Syndication Feeds" link with the rel="subsection".
Applying this XSL using this web service is where the work gets done. This consists of dereferencing each link with a rel="subsection" and transcluding the innards of the page at the end of the URL.
Notice that the URL of "Syndication Feeds" comes from a domain other than decafbad.com. If I wanted to, the third level of transclusion could've come from yet another domain, too.

I think this solution is better than using OPML for web directories. Although it could use some refinement—using a bit of <iframe> or AJAX magic to include in a page, perhaps—it's not only already supported by more applications than OPML, it also leverages a lot of prior art and consensus work.

So, am I wrong here? If so, please tell me how, where, and why.

Archived Comments

ryan king
2005-10-03T05:53:27

You're not wrong. This is very awesome.
Danny
2005-10-03T13:37:31

Bravo! I believe you've got the optimal approach to outline-style hierarchies on the Web.

Gopher NG here we come!

http://dannyayers.com/archives/2005/07/14/gopher-ng/
l.m.orchard
2005-10-03T14:18:23

Danny: Well, hey, if we're going to reinvent Gopher, we may as well do it right. :) Next, I set my sights on Archie--watch out, Google!
Sean Conner
2005-10-03T22:30:43

You're wrong because Dave Winer will say you're wrong for not using his format (dispite it being rather loosely specified).

But yeah, I thought that XHTML was modular and that you could use sections of it as needed, and that <UL> and <OL> are good enough for outlines. Seems pretty obvious to me.
Danny
2005-10-03T23:33:49

Ooh, Archie...yeah...
Isofarro
2005-10-04T14:21:22

Hmm, excellent idea to use rel="subsection" - that make so much sense. I have a few Ajax based outliners lying around handling things from ul/li lists, atom feeds and opml outlines. I should pull it all together and prototype what you've suggested above. (I think I also have an OPML-friendly PHP proxy to "alleviate" the cross-domain security measure - should be able to hack it to accept XOXO-like outlines)

Step two would be some WikiSyntax additions to author the above on a wiki (for instance defining transclusion links).

A kerfluffle of OPML and web directories

2005-10-03T03:21:56+00:00

So, I guess there was a bit of an extended kerfluffle over the weekend. And as these things usually do, it started out from a very cool idea: You can build a web directory as an outline of links, with some nodes "farmed out" to outlines hosted elsewhere—all through the magic of transclusion.

For example, say you want to host a directory of resources on web development. But, you might like to let me maintain the section on web syndication feeds. Well, I can toss you a URL to my outline of RSS and Atom links, and you can just pull it into a branch of your "superset" outline—kind of like an RSS subscription, really. Whenever I change my outline, yours will automatically get updated with my work.

Now, imagine this going off into infinity in both directions: Outlines including outlines including outlines. Outlines included by outlines included by outlines. It's a world-wide outline.

So, anyway, TechCrunch's brainstorm lead to Dave Winer's kudos and Scoble's OPML evangelism and an implementation challenge. But, to this, James Robertson responded by calling OPML a "really, really crappy format".

From this ensued a splattering of posts in various places chiming in on both sides:

OPML is a sucky and under-specified format, with implementations subject to approval by one guy.
OPML is a working format already in use by lots of code, so offer something better or shut up.

Now, Shelley Powers of Burningbird says that the "put up or shut up" attitude is wrong, that it's "bad technology". And, though I do agree with her, the problem is that the usual suspects involved in these sorts of kerfluffles fall on two sides:

We want to see good, well-specified agreements before we code something useful.
We want working, useful code that we'll agree is good when we see it.

While group #1 is willing to talk/shout things out and reach consensus ahead of time, group #2 wants to forge ahead with machines in motion and reach consensus through popular implementation. So, members of group #2 will never take group #1 seriously until they've "put up", because that's their process.

Personally, I sympathize with the dirty ways of group #2. But, I've become convinced that what group #1 does is best over the long term, as some of the early successes of group #2 may become tottering unbalanced stacks of plates later on.

So... What to do? Bah, I don't know. But, against my better judgement, I feel like I have an idea or two to "put up".

In the meantime: Members of group #1, stop arguing with members of group #2—you're not speaking in quite the same languages, and you're not going to convert anyone. Just nod & smile, walk away and come up with a better idea, come back and show why it's better.

(Oh yeah, and whatever happened to OML replacing OPML?)

Archived Comments

Julian Bond
2005-10-03T07:50:53

Both groups are right. The problem is that standards without implementations are just academic wanking. And implementations without standards won't get widespread adoption.

What's intensely irritating is the egos involved who can't see the truth in the above statement. It should be possible to criticise OPML as a standard while still applauding the experiments and without necessarily offering an alternative. If done with respect, just the criticism on its own should move the debate onwards.
Julian Bond
2005-10-03T07:57:10

Re OPML based SuperOpenDirectories. It is indeed neat. But I'm still struggling to see the point. Does it just re-invent Gopher? Then there's the inspired chaos of it all. At least with something like DMOZ, Yahoo, Wikipedia, the hierarchy has some formalised structure and editors (perhaps community editors). An open mesh of decentralised outlines is going to have lots of dead ends and missing cross links. Perhaps that's just an artifact of the browser Apps we've seen so far and the breadcrumb approach being used. Perhaps it doesn't matter.

And finally, I'd love to see an OPML browser app written in PHP. Perhaps I'll write one.
phil jones
2005-10-10T04:06:28

I'm definitely a group #2 person. But I have a slightly different take on what that means.

When group 2 people ask for working code, they aren't asking simply for "working code". (Such as your XOXO & XSL thing) They're thinking of an entire system of real users, a real application (need / problem to be solved) etc.

The reason Dave Winer and OPML will win this, is because Winer really wants shared outlining on the internet. And he knows "why" he wants it. He has a vision, and a passion for it. He knows what he wants to do with it. He knows how to make interesting applications with like-minded collaborators.

You can come up with a "better" format than OPML. You might be able to knock off better code overnight. But you do it for a "lark" or for some principle of "doing it properly".

Winer doesn't care if its "crappy". He just has a drive to make something happen, and OPML is the simplest thing that can possibly work to do that.

I think that's exactly the right thing to bet on.

When you say "I’ve become convinced that what group #1 does is best over the long term, as some of the early successes of group #2 may become tottering unbalanced stacks of plates later on."

I'd be interested in some real world examples. As I see it, "worse is better" is the golden rule of computer history, in the long as well as short term.
l.m.orchard
2005-10-10T11:34:30

Phil: I've watched Dave's push for shared outlining for awhile now, and certainly he's been working towards it for much longer than I've been watching.

And, though it's gotten some mileage through Dave's sheer exuberance and people infected by his cool ideas, it's never quite caught on. Instead, things like wikis and JotSpotLive and Backpack and SubEthaEdit have been capturing the users.

And now, this latest push doesn't look so much like shared outlining per se, but more like a new attempt at DMOZ. And since Google's pretty much driven a stake into DMOZ, my further interest in Gopher NG is really just a sometimes-interesting problem.

I could see some people joining Dave's World Outline effort to get some buzz in their interest niches—trying to be first to get their constituent URLs placed in the new, distributed OPML DMOZ-killer. And it might be nifty for awhile, but I doubt it'll take hold.

But as for real world examples of shared outlining, in the particular form Dave's pushing right now... Look at just about anyone's blogroll. They're almost all in XOXO form right now. That's the thing: XOXO is just an HTML list. It's so unexciting as to be unremarkable—but they're everywhere, right now. Hell, even OPML has to get converted to XOXO to be used with web browsers—unless you're falling back to some ugly form of tables-as-list.

XOXO is actually the simplest thing that can possibly work, and people are using and have been using it all along. I think that's the right thing to bet on, versus OPML. It doesn't need any evangelism or adoption efforts, other than maybe to remind people of that what they're already using is itself a viable format. That's the only reason XOXO has a name.

I've already shown an in-browser XOXO editor prototype—and believe me, that was easier to implement reliably than anything I've tried with OPML. I could turn that into a full flown app given sustained free time and interest. I plan to do that eventually, with a project I've got simmering.

Will I do it? Who knows—I'm a busy nerd, and I certainly don't have the constant ebulience, time, and money that Dave Winer has. All I can do is call shenanigans and preach to the choir.