As is traditional with Xanadu documents, terminology has shifted between this proposal & the eventual full system documentation (as of the open source release of Udanax Green in 1999).
Based on the descriptions given (from what I can tell by skimming the first couple pages), ‘orgl’ seems to be an early term for what the Green FeBe document calls ‘POOMfilade’ (for Permuation Of Order Matrix eNFILADE), & ‘v-stream’ appears to be an early term for what is now called ‘concatext’.
Current Xanadu implementations (post-1992) do not have v-stream addresses.
The Green FeBe documentation is here & my work on getting Green to build and run on modern linux is here.
I love this warning on the cover:
Morningstar explains in the post:
Sadly, that sentiment isn’t completely gone from the project.
If Ted published all the recent internal documentation, we’d probably see an awful lot of totally independent implementation of the more interesting ideas. (This is how he found me: I had been doing implementations of ideas that had been published – Udanax Green stuff or ZigZag stuff – and somebody found one of my projects on Hack-a-Day & notified him. I needed to unlearn a lot because the documentation I had been reading was incomplete and often misleading.) But, he thinks he still might be able to turn this into a profitable business before his death, & planning for that possibility (along with having been bitten by TBL & Andries Van Dam, among others, releasing things based on his work without solving problems he solved) is preventing him from seriously adopting plan R at this stage.
When I worked on the project, I was privy to information that was considered trade secrets. This was only half a decade ago. (Luckily, the material that had been trade secret got patented, so I can talk about it now.)
It’s very likely that when he dies everything will be released. After all, almost all the XOC stuff got released 20 years ago.
A little bit irrelevant, here is a recent interview of Ted Nelson.
I was looking at Xanadu recently mostly out of curiosity, and everything that Ted Nelson says feels really hand-wavy and more like coming from the perspective of a potential user, rather than someone who is designing a protocol, or markup, or suite of tools - or whatever Xanadu actually is. In fact, the more I read about the work that’s been done on Xanadu, it just feels like WWW with a prettier markup language (and transclusions, which would be super useful). It feels like the vast majority of what Xanadu aims for can be accomplished with HTTP and a markup language. Is it really this simple, or am I missing something?
I am aware, however, that this came about long before the world wide web was invented - but while WWW was actually implemented, Xanadu was merely a bunch of good ideas that someone wrote down.
Ted is mostly concerned with user experience, and he is not a programmer. When he writes things up, he generally frames it from a user perspective, rather than a programmer perspective. (This is a problem, because he’s surrounded by very skilled & smart programmers, & has clever and solid solutions to a lot of problems that he doesn’t articulate in his documentation.) It’s a problem that I tried to resolve in my documentation of Xanadu designs aimed at engineers.
The document linked here doesn’t have that problem, because Ted didn’t write it – it was written by the XOC team at Autodesk. As a result, it’s full of details of data structures and actual pseudocode implementations of operations.
Xanadu does not use embedded markup, because embedded markup breaks consistency guarantees. It’s not really reasonable to look at Xanadu as a ‘better Web’, in the same way it’s not really reasonable to look at haskell as a ‘better C++’: Xanadu designs are built on strong guarantees about consistency & simple but nuanced relations.
Basically: embedded markup breaks the concept of transclusion, because embedded markup confuses structure (which is part of formatting) with content. This means that, in order to reliably reuse content, you’d need to actively strip markup in complicated & messy ways, encouraging a separate layer that pretends it’s not there – but such a layer would break guarantees about data being static, & those guarantees turn things like bidirectional linking from impossible to trivial.
Now, over time, newer implementations have ditched some of the theoretical simplicity of XOC-era designs in favor of wholesale adopting some web tech. For instance, all implementations since 2007 (and possibly earlier) have used HTTP for transfer – which means that we are in the same boat as the web in terms of guarantees about documents remaining static & not disappearing. (I pushed hard for IPFS integration for this reason.)
The enfilade structures described in the XOC document here & used in Udanax Green are not used in modern implementations (in part because the people doing new implementations don’t have the strong mathematical background that Mark Millar & other folks doing the general enfilade theory in the late 70s had, and in part because computers have gotten fast and pipes have gotten thick so the performance benefits that these implementations provided to people dialing into a Sun workstation from their C-64 are no longer really relevant). Instead, we have EDLs written in a human-readable CSV-like format, transferred over HTTP, & we use standard HTTP features for partial fetching for transclusion purposes when available (but since they’re usually not, we typically download the whole thing & chop it up ourselves… actually, OXU and Xanadu Cambridge may not even bother with partial fetches or with sparse caches, but XanaSpace did because our aim was viewing & editing seriously huge corpora – like legal precedent and such).
Xanadu has an awful lot of implementations. Unfortunately, none of them are fully complete. (Udanax Green is usable – you can view & edit documents in it with the PyXi interface, & it’s been open source for 20 years – but it has some bugs that cause occasional text corruption. OpenXanadu & Xanadu Cambridge, from 2014 and 2016 respectively, are fully functional web-based translit viewers, but they don’t ship with fully featured editors & SOP limits their functionality.) We just never had as many dedicated developers on a single Xanadu implementation as there are on a single modern web browser.
What I’m wondering every time I read about Xanadu is how the entire concept of transclusions is supposed to be transported from a hypertext to a hypermedia world: It’s nice to have some standard to say “this paragraph comes from document X” and have that transclusion available with context and revisions (just that Xanadu didn’t manage to get there yet), but to make that work with video, for example, is another several layers of complexity:
Video A stating that frames 3000-3500 contain a cut-out of Video B’s frames 9000-9250 at 0.5 speed, pasting pixels (0,500),(100,600) to (50,200),(60,210), scaling it (and maybe make it translucent or reflective?) will be fun. There’s SMIL and similar formats to express such a situation, but how is context, different versions, etc supposed to work? And how are users supposed to edit in such an environment?
We had some different specs for that. Video in particular was extra complicated. I was in favor of combining our proposals for audio (where units were in seconds) & images (where we had a bounding box or a bounding polygon). Because video is highly compressed & has a sliding window compression, it’s hard to fetch only the bytes you need, & doing so in the implementation requires exposing bits of the video format internals that easy-to-use video decoding libraries don’t typically expose.
Last I heard, we were just going to use the W3C media fragments standard in new implementations (which typically use HTTP for transport by default anyhow). W3C media fragments overlaps somewhat with SMIL, but doesn’t support bounding polygons / masking IIRC. The only site I’m aware of that supports any of it is youtube, so we don’t really gain anything by sticking to the spec.
Because transclusion is so easy to screw up (with off by one errors and such), the expectation is that editing support would be built into the viewer & editing and viewing would be firmly integrated. Unfortunately, the xanadu releases haven’t had editing in a usable state – Ted prioritizes getting the view right because editing uses all the viewing mechanisms, or is supposed to, but that means editing support lags behind view support (and because people writing these implementations rarely stick around for more than a couple years & a single implementation rarely gets multiple generations of developers, editing often doesn’t get implemented at all). This is a real shame, because we’ve got editor designs that are at least as interesting as the viewer designs from a UX perspective.
The only proper Xanadu editor I’m aware of is the (crappy) one I wrote for OpenXanadu – a three-column job called SPANG that operates by sticking highlighted sections in a clips bucket & allowing users to insert those clips into a new document. This is conceptually the model that transclusion-based editing is supposed to have, but we wanted better support for splitting & editing the clips, adding keyboard input, and rearrangement – specifically, we wanted a canvas with free-floating clips that could be dragged together & snap into place.
Non-text clips were supposed to be edited in the same way – which is more conventional for audio and video, since it resembles how a non-linear video editor works. (This should be unsurprising: a lot of Ted’s ideas about editing in a transclusion-based environment come from habits he picked up editing video by cutting up film & taping it together.)