The Technical Architecture of Project Xanadu

• entered text is appended to the invariant stream, thereby being given a coordinate we can use to reference and recall it

• at the same time, a link is created to represent the position of that new text within a document, which is a variant stream

  these are NOT the jump links you may be used to on the WWW, but rather content links that relate a range of positions in the document to pieces of content that make up the document

  (insert diagram of 2-way link from invariant to variant)

  A document is a variant stream because its content will change over time, as the author rewords, deletes and rearranges his content.

As the author edits his document, behind the scenes links are created, deleted, adjusted to map the specific invariant content he wants into the places in the document that he wants.

• new text is always appended to the invariant stream, so no shifting text around is needed.
• links give us a fast way to logically rearrange or remove text

At some point the author wants to save his work, declaring it to be draft version 1, and continue making changes

A new document, related to the first, is conceptually created. Since the invariant content is, well, invariant, the invariant stream is used by both the old and new document.

Since the author wants to make further changes without disturbing the old edocument, all of his links are copied into the new document. In this way the editor can modify the copy of those links to move, add or delete text in the new document.

• there is only one copy of any text, regardless of placement or non-use
• either version of the document can be viewed, giving us history
• each document has its own layout and, since a document is versioned, some content may appear in different places in different versions.
• programmatically we can query the links for both documents and figure out where a specific paragraph or phase has moved to, giving us a diff.

Notice that the links are associated with a particular version of the document, and that most of them are unchanged across versions. Yet we have duplicated them in each document.

What if instead we applied the same technique to the links as we have the text, keeping only a single copy and selectively mapping each into a document?

So we store the links in the invariant stream as well, sharing them all across all versions of the document, and when a link is relevant to the current version it is mapped in as well.

To do this we give every link another leg – so we have the from, the to and the home leg. The home leg points to the specific version of document to which it applies, so if a link only points to version 1 but not version 2, the content addressed by that link is omitted in version 2.

We make the home an endpoint instead of just a reference of a specific document/version, because versions themselves represent a numberline or dimension e.g. version 1, 2, 3, 4, … This allows us to say that a link's home is on a range of versions, again avoiding duplication of links.

• so we have a single copy of all text and links, no storage duplication
• queries are more efficient to make that tell us which content is used in which versions

So far we've seen content links, which map text into places within a document, but links are far more powerful. One use is altering presentation, as any document system needs boldface, italics, underline and so forth.

So let's distinguish between link types, by giving them a fourth endpoint, called type.

Again we make this an endpoint instead of a set of type constants, we can declare any number of link types and arrange them by function. So all the presentation link types are grouped into a range, and all the content link types are grouped into another range of the type dimension.

• This allows us to query for all presentation links (for the front-end to mark up the presentation) or all content links that point to the first quarter of the document.
• the dimension of types is open-ended; new ones can be easily added