purple-include: Granular Transclusions for the Common Man

Posted on Published by Eugene Eric Kim

Many thanks to Jonathan Cheyer, Craig Latta, and Kaliya Hamlin for coming to the HyperScope sprint this past weekend, and special thanks to Christina Engelbart for hosting. Also thanks to Thom Cherryhomes and others who hung out with us on IRC. The notes from the day are up on the Wiki, and I put up some pictures as well.    (MEL)

https://i0.wp.com/farm2.static.flickr.com/1134/681861752_857ef74d28_m.jpg?w=700    (MEM)

The big news, though, is that Brad, Jonathan, and I wrote a cool hack called purple-include, based on Mark Nottingham‘s most excellent hinclude. It lets you transclude granular chunks of content from any web site by using an img-like tag. Check out the examples. I think this will go a long way in making Transclusions more common on the Web.    (MEN)

You address granular content either by using a fragment identifier that the document author provides (such as a Purple Number) or by using an XPath expression. Thanks to Tony Chang for his cool interactive XPath tester.    (MEO)

The planned next step is to create a Firefox plugin that adds a “Transclude” option when you right click inside of a browser text widget. This will allow you to transclude copied content, rather than paste it. Don’t know whether any of us will get to this soon, so we encourage the lazy web and all you Firefox hackers to beat us to the punch.    (MEP)

This was my first non-trivial foray into JavaScript, and I was disturbed by what I saw. The language itself is not horrible, although its object system makes Perl 5 look like Smalltalk. What’s shameful is its API support. We had to use a very ugly, although apparently common hack to get a DOM of external web pages. This is pure silliness. The browser is already doing the hard work of parsing broken HTML and XML and turning it into a DOM. Why not easily expose that functionality to the developer?    (MEQ)

As Brad dryly noted, “Welcome to my world.”    (MER)

URI Syntax for the HyperScope

Posted on Published by Eugene Eric Kim

At last Tuesday’s HyperScope meeting, Jonathan Cheyer and I spent an inordinate amount of time debating the syntax for HyperScope URIs, much to the amusement and chagrin of our peers. Although the topic may seem insignificant, it is actually quite layered with no easy answers. I’m going to summarize the issues here. Most of you will probably not care about the intricacies of the argument itself, but at minimum, it should reveal a bit more about the project itself.    (KI2)

HyperScope is meant to be a transitional tool that will enable people to play with Augment‘s more sophisticated capabilities within their existing environments. In the immediate future, that means the Firefox web browser (and probably Internet Explorer as well). In the not-to-distant future, that could extend to a range of applications, from Eclipse to OpenOffice and beyond.    (KI3)

This intent strongly informs our requirements. In particular, we need to make sure we are bootstrapping the system on top of existing technologies (such as URIs) effectively and correctly, and we need to make sure the system is evolvable. Both of these requirements play a big role in our debate.    (KI4)

So what’s all the fuss about? One of Augment‘s coolest (and most fundamental) features is its sophisticated addressability. The example most folks know about manifests itself as Purple Numbers, namely the ability to reference a specific node in a document in a standard way. But Augment can do much, much more. It can do path expressions, similar in spirit to XPath, which allows you to reference some subset of nodes in a document. (See my notes on transcluding a subset of nodes via Purple Numbers).    (KI5)

You can also embed View Specs in an address. For example, suppose you decided that the best way to view a page was the first level of nodes only. You could specify that as a View Spec in the link itself, so that when someone followed that link, they would see only the first level of nodes rather than the entire document.    (KI6)

With the HyperScope, we’re bringing these capabilities to the plain ol’ World Wide Web — that is, assuming your client knows how to interpret these addresses properly. With our initial release (due September 2006), this will require loading a JavaScript library. All document addressability will happen entirely on the client-side. This is a good thing for a lot of reasons, the most important being adoptability. It will be easy for people to play with the HyperScope. All they’ll have to do is click on a link in Firefox (and probably Internet Explorer).    (KI7)

However, the fact that we’re doing a client-side only version of the HyperScope does not preclude the creation of a joint client/server version or even a mostly server-side version where the client is essentially a dumb web browser. In fact, we’d encourage the creation of both. We don’t care some much about implementation as we do capabilities and interoperability.    (KI8)

Here’s the question: How should we include these extended addressing capabilities in real-life URIs?    (KI9)

There are three possible solutions:    (KIA)

  • Embed them as a fragment address (i.e. following a hash mark at the end of the URI).    (KIB)
  • Embed them either as part of the path or query string parameters (i.e. following a question mark at the end of the URI).    (KIC)
  • All of the above and more.    (KID)

I side with the first and third solutions. Jonathan thinks it should be the second.    (KIE)

Fragment Address    (KIF)

Pros:    (KIG)

  • These extended capabilities seem to belong here semantically. Purple Numbers are an obvious example of this. XPointer is another.    (KIH)
  • The URIs will be bookmarkable as the user manipulates the document from the HyperScope. We can do this, because we can change the fragment identifier from within JavaScript. We can’t do the same with any other part of the URI.    (KII)

Cons:    (KIJ)

  • These URIs cannot be used for a server-side only solution, because HTTP does not pass the fragment identifier to web servers.    (KIK)

Path or Query String    (KIL)

Pros:    (KIM)

  • Can be used for client-only or server-only solutions, or anywhere in between.    (KIN)

Cons:    (KIO)

  • You’re still left with the problem of a standard addressing syntax that doesn’t interfere with any other kind of addressing. For example, if you’re going to use a query parameter, what do you call it? Granted, if you namespace it correctly, the likelihood of namespace clash is tiny, but it’s still there.    (KIP)
  • No one’s building a server-side only solution right now.    (KIQ)

Why Limit Yourself?    (KIR)

This is ultimately my argument: Go with the first syntax for now, because it best suits our current needs, and don’t worry about the fact that it won’t satisfy all potential future needs, because nothing will. What’s important is that we standardize the conceptual semantics, and then standardize the syntax to the extent possible. In all likelihood, most people will be passing these links around by copying and pasting them anyway, so the actual link syntax isn’t completely critical.    (KIS)

Purple Numbers and WIKIWYG

Posted on Published by Eugene Eric Kim

For a while, it was looking like I was going to break another personal blogging record last month, then things got so busy I had zero time to blog whatsoever. That means I’m in catch up mode again, so as usual, I’ll post in reverse chronological order (which in the blogosphere is really reverse reverse chronological order).    (JYN)

Yesterday, I spent the afternoon at Socialtext, where they were having an all-hands meeting. They graciously invited me to participate in the Open Space segment of their gathering, which meant quality time with Chris Dent and a rare opportunity to evangelize the Church Of Purple together. Of course, Chris has been spreading the Purple religion at Socialtext for a while now, so it wasn’t as much about evangelism as it was about next steps.    (JYO)

As I’ve mentioned many times before, browser-based WYSIWYG editors are an exciting development because they allow us to make Purple Numbers transparent in the authoring process. Right now, when you edit a PurpleWiki page, you see the node ID tags (e.g. {nid 123}). This is impossible to get around with the default browser text-editing widget. However, with a WYSIWYG editor, you can hide the Purple Numbers while still maintaining their associations with a node behind the scenes.    (JYP)

That’s the theory, anyway. In particular, I’ve been excited about WIKIWYG ever since Ross Mayfield showed me an early prototype last August. I had a personal bias, since Chris Dent and Matt Liggett helped write it, as did Casey West and the inimitable Brian Ingerson, whom I finally met last weekend at Tag Camp.    (JYQ)

Yesterday afternoon, we discussed Purple Numbers and WIKIWYG, and it was good. Then in the evening, Ingy and I spent a few hours trying to get WIKIWYG integrated into PurpleWiki.    (JYR)

We didn’t quite make it. Our biggest roadblock was a bug we discovered in Mozilla’s design mode that we can’t do much about. (My days of statically typed languages are well behind me.) But, we got something somewhat working, and I learned a heckuvalot. You can play with our semi-working demo.    (JYS)

WIKIWYG seems well-architected and is easy to customize. For folks with relatively standard Wiki editing requirements, I highly encourage you to play with it. PurpleWiki has some special formatting funkiness (mainly due to the Purple Numbers), but we were able to get around this fairly easily. (This was also true thanks to PurpleWiki‘s model of parsing to an intermediate data structure, then using view drivers to serialize. I wish more Wiki engines did this. I know Magnus Manske is thinking about doing this for Mediawiki, and I think Janne Jalkanen is already doing it with JSPWiki.)    (JYT)

The Mozilla bug annoyed me, because it’s a show-stopper in some ways, and there’s not much I can do about it. I didn’t realize it, but all of the JavaScript WYSIWYG widgets actually switch to the browser’s “design mode” in order to handle WYSIWYG editing. As with many HTML editors, design mode does not handle structure cleanly, and you end up getting weird artifacts such as spurious break tags. Our problem was that we serialize node ID information as id attributes in the HTML tags. However, Firefox does not maintain those attributes correctly when you move content around.    (JYU)

I’ll report the bug (if folks have suggestions as to the best way to bring this to the right people’s attention, let me know), but it also puts the kibosh on my hopes for WIKIWYG and Purple Numbers. Even if the bug is fixed in the next version of Firefox, we’re still prey to all the folks using older versions as well as Internet Explorer or Safari, which have their own problems with design mode.    (JYV)

Chris and I discussed one workaround that I’m still pondering: render the Purple Number and have users be responsible for maintaining the association with the nodes. That’s the status quo, except users are doing it in WikiText rather than in WYSIWYG. Doing it in WYSIWYG certainly lowers the bar, and it’s probably the next best thing for us to do.    (JYW)

Purple Numbers: Optimized for Synthesis

Posted on Published by Eugene Eric Kim

Chris Dent has been having some good exchanges about Purple Numbers with Adina Levin and Phil Jones. I don’t have much to add, as I think Chris is spot on. Two comments struck me, though.    (IQV)

First, Phil claims that Purple Numbers are optimized for reading at the expense of writing. His point is that Purple Numbers, as currently implemented, add overhead to the writing process, whereas the pay-off comes for the reader. I emphasize as currently implemented, because we just haven’t gotten around to making them mostly transparent in the writing process. Hacking one of the WYSIWYG JavaScript text editors to support Purple Numbers should do the trick.    (IQW)

However, I really liked Chris’s response:    (IQX)

Yes, purple numbers do try to favor the reader and the act of reading, but not just for reading. They favor the reader so the reader may more easily do more writing. The whole point is for purple numbers and tools like it to be a generative force in the synthesis of new understandings.    (IQY)

Phil can write all he wants, and I can read all I want, but until I write down something that builds on what Phil says, while making chains of reference back through the many layers of context, there’s been no synthesis, at least not any that is available outside the confines of my own mind.    (IQZ)

Granular Addressability enables synthesis. Wanna know what makes blogs conversational? Permalinks, which are a form of Granular Addressability.    (IR0)

A lot of people don’t get this. I read The Sports Guy over at ESPN.com all the time (despite the fact that I hate all Boston sports teams with a passion), and at the past two Super Bowls, he wrote what ESPN.com called a “blog.” It sure looked like a blog, but in reality, it was just one-way publishing. Folks couldn’t comment on his entries, because they couldn’t link to any of them. I see this all the time with other major media outlets trying to jump on the blog bandwagon.    (IR1)

Which brings me to the second comment that jumped out at me. In his response to Adina, Chris wrote:    (IR2)

Clearly I am in far too deep with purple stuff: I need a translator. The above can be so much meaningless noise and I find little time to make things cogent.    (IR3)

I’m not the best proselytizer of Purple Numbers, not because I’m not proud of them (I am), not because I don’t value them (I do), and not because I can’t explain their value clearly (I can). There’s a tremendous amount of deep thinking underlying these little purple critters, and the implications are fascinating. But before you can understand any of this, you’ve got to care. And unless you’re one of those strange individuals who just gets it, you’ve got to try them before you’ll buy them.    (IR4)

A lot of folks think I invented Purple Numbers. Not true at all. I was one of those folks who didn’t care, one of the first in fact. Purple Numbers are an HTML manifestation of Augment’s granular addressability scheme, invented by Doug Engelbart and made purple years later by his daughter, Christina Engelbart. When I first started working with Doug, he kept insisting that all of our knowledge products on the Web have Purple Numbers. I didn’t think it was a priority, but I knew I could easily whip up a tool to generate them, so I wrote Purple to humor him. Then a funny thing happened. Once I had them, I used them, simply because they were there. Then I started missing them when they weren’t there. Then it dawned on me: These little purple thingies sure were darn useful. And I started thinking about why.    (IR5)

The point of my story is this: I’m perfectly happy to have a deep, convoluted discussion about some esoteric aspect of Purple Numbers. If you don’t believe me, try me. Or read my blog entries on the matter. But if you really want to understand why they’re so important, just give them a try for a month, then try living without them.    (IR6)

Tim Bray on Purple Numbers

Posted on Published by Eugene Eric Kim

I’ve long been a fan of Tim Bray‘s work, and although we had never crossed paths before, I had always assumed it would be instigated by me making some comment about something he had done or written about. (A few months back, I emailed him about ballparks in the Bay Area, because we seem to share a love for the sport, but that doesn’t count.) So I was surprised and pleased to see that Tim had made first contact and had (temporarily, as it turned out) implemented Purple Numbers on his blog. Not surprisingly, this is starting to generate some talk in the blogosphere. In particular, see:    (1G9)

Chris has done an excellent job of quickly addressing many of these issues. I’ll just toss in a few thoughts and references here and will look forward to more feedback.    (1GE)

Stable, Immutable IDs    (1GF)

Several people have pointed out that the IDs need to be stable. In other words, as the paragraphs move around or as new ones are added or deleted, the IDs stick to their original paragraphs. This was a fundamental motivation for Engelbart’s statement identifiers (SIDs), which we have renamed node identifiers (NID).    (1GG)

Both Purple (which needs updating) and PurpleWiki handle this correctly. You’ll notice that the addresses are stable on my blog and on Chris’s, as well as on all of the PurpleWiki installations (e.g. Collab:HomePage, PurpleWiki:HomePage). It’s because we use plugins for our respective blog software that call PurpleWiki‘s parser, which manages NIDs for us.    (1GH)

By using PurpleWiki to handle the purpling, blog content has NIDs unique to both the blog and the Wiki, which allows us to do fun stuff like transclude between the two. We get a similar effect with perplog, the excellent IRC logger written by Paul Visscher and other members of The Canonical Hackers. For example, check out Planetwork:Main Page and the chat logs over there.    (1GI)

Mark Nottingham noted that even if the NIDs are stable in the sense that they are attached to certain paragraphs, the paragraphs themselves are not semantically stable. This is a point on which I’ve ruminated in the past, and we still don’t have a good solution to it.    (1GJ)

History and Other Worthy Projects    (1GK)

I’ve written up my own brief history of Purple Numbers, which fills in some holes in Chris’s account. In it, I mention Murray Altheim‘s plink. Plink is no longer available on the net, because it has been subsumed into his latest project, Ceryle. Everything that I’ve seen about Ceryle so far kicks butt, so if you’d like to see it too, please drop Murray an email and encourage him to hurry up and finish his thesis so that he can make Ceryle available! You can tell him I sent you, and you can forward him the link to this paragraph; he’ll understand.    (1GL)

Matt Schneider is the creator of the PurpleSlurple purple numbering proxy, which will add Purple Numbers to any (well, most) documents on the Web. PurpleSlurple deserves a lot of credit for spreading the meme.    (1GM)

Mike Mell implemented Purple Numbers in ZWiki for last year’s Planetwork Conference (see ZWiki:ZwikiAndPurpleNumbers), which in turn influenced the evolution of Purple Numbers in PurpleWiki. Mike and Matt have both experimented with JavaScript for making the numbers less intrusive.    (1GN)

The latest version of the Compendium Dialogue Mapping tool exports HTML maps with Purple Numbers.    (1GO)

In addition to Murray, Matt, and Mike, several other members of the Blue Oxen Associates Collaboration Collaboratory have contributed to the evolution of Purple Numbers, especially Peter Jones, Jack Park, and Bill Seitz. In addition to his contributions to the technical and philosophical discussions, Peter wrote the hilarious Hymn of the Church Of Purple and excerpts of the Book of the Church Of Purple.    (1GP)

Finally, many good folks in the blogosphere have helped spread the meme in many subtle ways, particularly those noted connectors Seb Paquet and Clay Shirky.    (1GQ)

Evangelism and The Big Picture    (1GR)

Okay, that last section was starting to sound like an award acceptance speech, and although none of us have won any awards, one thing is clear: The contributions of many have vastly improved this simple, but valuable tool. I’m hoping that momentum picks up even more with these recent perturbances. I’m especially heartened to see experiments for improving the look-and-feel.    (1GS)

I want to quibble with one thing that Chris Dent said in his most recent account. (When we have distributed Purple Numbers, I’ll be able to transclude it, but for now, you’ll just have to live with the cut-and-paste):    (1GT)

When he [Eugene] and I got together to do PurpleWiki, we were primarily shooting for granular addressability. Once we got that working, I started getting all jazzed about somehow, maybe, someday, being able to do Transclusion. Eugene was into the idea but I felt somehow that he didn’t quite get it. Since then we’ve implemented Transclusion and new people have come along with ideas of things to do that I’m sure I don’t quite get, but are probably a next step that will be great.    (1GU)

There are many things I don’t quite get, but Transclusions are not one of them, at least at the level we first implemented them. That’s okay, though. Ted Nelson felt the same way about my understanding of Transclusions as Chris did, although for different reasons. (And, I suspect that Ted would have had the same opinions of Chris.) I mention this here not so much because I want to correct the record, but because it gives me an excuse to tell some anecdotes and to reveal a bit about myself.    (1GV)

Anyone who knows Doug Engelbart knows that he complains a lot. The beauty of being an acknowledged pioneer and visionary is that people pay attention, even if they they don’t think much of those complaints. When I first began working with Doug in early 2000, I would occasionally write up small papers and put them on the Web. Doug would complain that they didn’t have Purple Numbers. At the time, I recognized the value of granular addresses, but didn’t think they were worth the trouble to add them to my documents. I also didn’t think they were the “right” solution. Nevertheless, because Doug was Doug, I decided to throw him a bone. So I spent a few hours writing Purple (most of which was spent learning XSLT), and started posting documents with Purple Numbers.    (1GW)

Then, a funny thing happened. I got used to them. I got so used to them, I wanted them everywhere.    (1GX)

A few people just get Purple Numbers right away. Murray was probably the first of those not originally in the Engelbart crowd to do so; Chris followed soon thereafter, as did Matt. The vast majority of folks get the concept, but don’t really find them important until they start using them. Then, like me, they want them everywhere. Getting people past that first step is crucial.    (1GY)

A few nights ago, I had a late night conversation with Gabe Wachob (chair of the OASIS XRI committee) on IRC. (This eventually led to a conversation between Chris and me, which led to Chris’s blog entry, which led to Tim discovering Purple Numbers, which led to this entry. Think Out Loud is an amazing thing.) Gabe knew what Purple Numbers were, but hadn’t thought twice about them. I had wanted to ask him some questions about using XRI addresses as identifiers, and in order to do so, I gave him a quick demonstration of Transclusions. The light bulb went off; all of a sudden, he really, truly got it.    (1GZ)

Richard Gabriel, one of our advisors, is well known for his Worse Is Better essays (among other things). I think Purple Numbers are an outstanding example of Worse Is Better. They fulfill an immediate need, and they cause us to think more deeply about some of the underlying issues. I’d like to see Purple Numbers all over the place, but I’d also like to see a group of deep thinkers and tinkerers consider and evolve the concept. It’s part of a larger philosophy that I like to call The Blue Oxen Way.    (1H0)

This last point is extremely important. Chris has thankfully been a much more enthusiastic evangelist of Purple Numbers than I have, and in the past he’s called me “ambivalent” about Purple Numbers. That’s not so far from the truth. It’s not that I’m any less enthusiastic about Purple Numbers themselves — I am a card-carrying member of the Church Of Purple, and the current attention and potential for wider usage thrill me. However, I’m cautious about evangelizing Purple Numbers, because I don’t want people to get too caught up in the tool itself and forget about the bigger picture. It’s the reason I didn’t mention Purple Numbers at all in my manifesto.    (1H1)

At the Planetwork forum two weeks ago, Fen Labalme, Victor Grey, and I gave the first public demo of a working Identity Commons Single Sign-On system. We were tickled pink by the demo, which to everyone else looked just like any other login system. The reason we were so excited was that we knew the system used an underlying infrastructure that would eventually enable much greater things. The demo itself, unfortunately, didn’t convey that to anyone who didn’t already understand this.    (1H2)

I’m probably a bit oversensitive about this sort of thing, and I’m constantly seeking better balance. But it’s always in the back of my mind. When I talk to people about Blue Oxen Associates, I usually spend more time talking about the sociological aspect of collaboration rather than the tools, even though I have plenty to say about the latter. Can Purple Numbers make the world a better place? I truly, honestly, believe that they can. (This is a topic for another day.) But when I see groups that excel in collaboration (or conversely, those that stink at it), Purple Numbers are usually the furthest thing from my mind. Much more important is the need to identify and understand these patterns of collaboration (of which tool usage is an important part).    (1H3)