0xDECAFBAD - Tag: microformats

i (heart) ficlets, microformats, and feed scrapers

2007-04-05T06:00:05+00:00

I've really got to reiterate / call out a few points from that last entry:

I ❤ making feed scrapers, although they're sometimes a pain.
I ❤ Microformats, for making scrapers easy.
I ❤ Ficlets for using Microformats and making it easy for me to use their site as an API using just XSL and HTTP GET.

I'd love to see more sites like Ficlets.

Archived Comments

Rube
2007-05-07T21:45:17

Ficlets == best software name EVER (at least if you speak German)

XoxoOutliner shows some signs of life

2006-11-12T05:25:40+00:00

Remember when I started writing about XoxoOutliner around 8 months ago? Yeah, lots has happened with life in general between then and now - but lately I've been working on code for it again. As you might see from my Trac timeline, I've got lots of new code checked in. And I mean lots.

If I can keep up this bout of serial enthusiasm for the project, you'll be hearing lots more about it soon.

For now, check out the new static README.html and the live demo. It's extremely bugful, but it might do interesting things for Firefox and Safari users.

Archived Comments

Vincent D Murphy
2006-11-12T09:14:26

Wow!

This thing is such an improvement. I love that the README is an outline.

I think this is really powerful. I think an outliner should eliminate the need for a lot of rich text browser editors. Outlines inherently break text into small little chunks, which are stylable (and potentially URL addressable, for block-level comments). I think this thing would rock in a wiki.

Keep up the good work!
Shawn Medero
2006-11-13T12:59:18

Bravo! This is a great set of updates and works well in Safari (haven't had the time yet to test in Firefox.)

I've been thinking about using some portion of these tools in my wiki software to dress up outlines. I'm not sure yet... sometimes I feel like editing an outline (well a simple one I'd use on a wiki at least) is quicker manually with something like Markdown.
misuba
2006-11-14T00:15:01

Rad!

Keep this up and I won't have to finish mine. :-)

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?

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.

Working on a Tripkodoo business plan tonight

2005-10-28T14:32:29+00:00

Your company name:
Tripkodoo
Your company product:
opml-based collaborative document editing via microformats

Oh, hell. It looks like Web Two Point Oh! has nailed me on one of my stewing projects, Micronian. Sorta. Minus the OPML, really.

Though, hey, Tripkodoo sounds like a cool name...

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.