0xDECAFBAD - Tag: xoxo

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.

XoxoOutliner and suboutline addressing

2006-11-13T09:34:02+00:00

Here's a feature I just hacked together for XoxoOutliner and plan to refine further:

Not entirely sure that this is how I want this to work, but these three URLs demonstrate the ability to address and fetch subsets of outlines. I'm hoping this will be a basis for selective transclusion in other outlines, or maybe even in a sidebar of a blog. (Which, depending on the blog software, might be built from outlines anyway.)

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?

Still Seeking an Exploded Tinderbox for Tiger

2005-11-02T06:03:10+00:00

This is a recurring thought: I still really, really want an exploded Tinderbox on Tiger. It could so become an über Spotlight/Finder replacement. I just don't seem to have time or ambition to write it.

I don't mention Tinderbox very often, but I've got a few Tinderbox documents set as Login Items on my PowerBook. So, this app has become ubiquitous on my machine for idea capture, sorting, and exploration. In fact, I used it to capture, shape, and structure everything I put into Hacking RSS and Atom.

However, I haven't ever gotten far into some of the more advanced features like agents or export templates. My most used HTML export templates simply boil an outline of notes down into XOXO, and that's about it. I have had further ambitions for richer Tinderbox export / extension, but I haven't pursued them much lately.

Really, my main reason for not delving into Tinderbox's advanced features is that learning and using them effectively would burrow me further into the app's own pocket universe of conventions and technology.

Since Tinderbox saves to XML, I can bridge to a larger information space via XSLT and XPath based tools. But, all the conversion and roundtrip can get kludgey and awkward—and I lose the ease of life inside text files augmented by grep, awk, sed, vim, perl, python, QuickSilver, and Markdown.

This is the point where I think opportunities presented by Tiger and the advent of Spotlight can come into play—especially with the availability of SpotMeta. SpotMeta weds Spotlight with HFS Extended Attributes in order to enable the management of arbitrary user-specified metadata on files in addition to Spotlight Importer metadata.

See, the main magic of Tinderbox—at least to me—is visualization and management of relationships between notions and microcontent. At present, Tinderbox needs to swallow the universe to accomplish everything it wants to accomplish. It needs to include word processor features and metadata handling and graphics and all.

But, what if Tinderbox could surrender all of those functions up to TextEdit and MS Word and other desktop apps? What if all of the "notes" in a Tinderbox document were just documents and files, and all of the relationships managed by Tinderbox (ie. spatial, links, aliased) were just encoded as extended attributes?

In this scenario, the file system is the Tinderbox document. Don't want to use your whole hard drive? Make a new disk image and compartmentalize things. Tinderbox could become the world's most revolutionary Finder rethink ever invented. And the thing is, I can see all of this being enabled by Spotlight and extended attributes.

Archived Comments

Robert Brook
2005-11-04T13:16:12

Much as I love Tinderbox, I just can't bring myself to completely trust it. The reasons? Similar to those mentioned below!

http://decafbad.com/blog/2005/11/02/why-proprietary

http://decafbad.com/blog/2005/11/02/why-microsoft
Lee Phillips
2005-11-07T15:06:19

I have been thinking along these lines, too. A while back I outlined a little kluge that allows you to use external editors with Tinderbox in a fairly transparent way (click on the note and the editor for that note's type opens up). In this way of working the note contents are maintained as external files, and Tinderbox is used to show their relationships:

http://lee-phillips.org/osx/tinderbox/tinderext/index.html

Lately I've been thinking that I would like to write notes using templates (Cheetah, etc.) and store their attributes in a standard database, then have .dot files produced by a python program to visualize relationships. All open-source, and portable to any unix-style system. HTML export would almost come free, using one of python's many web frameworks. You lose Tinderbox's direct manipulation, but you escape from its "universe" (with its non-Cocoa crustiness).
John Robert Cornell
2005-11-18T17:52:30

I've had the same thoughts about exploding Tinderbox for a while. Bruce Horn, one of the original members of the Mac team, is on to something similar: http://www.ingenuitysoftware.com/
Dowd McAllister
2005-12-23T22:20:57

I've been looking for something very similar. I like Tinderbox's simplicity and power, but for a while now, I've thought the tool would be easier to implement in Smalltalk http://www.squeak.org/

I'm just waiting around for Croquet http://www.opencroquet.org/ , honestly. Once that is released, I think the tool we're looking for would be almost trivial to build. (my ideal version of the tool includes network awareness and collaboration)
Joe Mazz
2006-03-20T09:38:28

What intruiging ideas you are discussing here! You have struck a chord with my own hesitation to dive head-first into Tinderbox (TB)--- the need to import (or re-enter) all my key note content into its own "information repository," which even then would be only loosly connected to all the rest of the "notes" in thousands of other files on my computer. Another big limitation is its inabiliy to link notes between TB documents.

It appears that Spotlight+SpotMeta provide the GUI to assign arbitray searchable attributes for file content, and SmartFolders provide some of the key functionality of TB agents. And I suppose symlinks in the OS effectively duplicate the primary role of TB aliases (notes that can appear in any number of other locations in the hierarchy). But these still cover only portions of the functionality of Tinderbox.

What would provide the visualization component of TB that represents files as glyphs (at least like TB map view's "boxes", if not something more flexible and graphically rich), and that enables users to interactively create hyperlinks between files by drawing lines between them? Has anyone here come across, or perhaps started developing, a tool that can simplify (graphically) creating hyperlinks between UNIX files? Under the hood, clearly such a GUI would be making and breaking extended attributes shared in common between selected sets of files in the HFS+ file system.

A recent post at macrumors.com suggests our creative friends at Apple are perhaps already onto this idea (for Mac OS 10.5?): http://forums.macrumors.com/showthread.php?t=156291&page=6

From the rumors I'm hearing about the next version of Spotlight and the possibility of creating linked relationships between objects, it should be exciting times.

How about the assignment of attributes to the hyperlinks between documents (another unique and powerful TB feature)?

And what would represent the TB function of templates and agents for automated formatting of selected content for HTML or XML documents by combining information from various files ("notes")? I suppose this could be programmed/scripted in any number of ways, using say Python or even Automator or AppleScript.

The possibilities truly are endless.

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.