XANADUÆ CONNECTED LITERARY STRUCTURE
Theodor Holm Nelson, Founding Designer, Project Xanadu
© 2012 Project Xanadu.
TRADEMARKS. XanaduÆ and ZigZagÆ are registered software trademarks of Project Xanadu. XanaduSpaceô, Xanadeskô and Xanaduleô are claimed trademarks of Project Xanadu.
Xanadu is not just a format for an electronic document, but a design for a whole interconnected system of literature, based on visible interconnection of pages side by side. SEE DEMO ON YOUTUBE, below.
It is intended for collaboration, annotation, controversy, large-scale document management, remix, and much more.
Xanadocs (Xanadu documents) are entirely different from the popular types of electronic documents (.doc, .pdf, .html). From our point of view, all these are alike-- paper simulations which show no connections. These conventional formats also scramble coding into the content ("embedded markup"). This is very limiting.
Our system exploits possibilities of interaction that paper simulation cannot. It is radically different from the other text systems, though in some ways much simpler.
- visible connection
- side-by-side intercomparison
- deep annotation
and many other properties which are impossible in the conventional model.
For instance, every portion of content remains connected to its original source, which is important in many fields. (Contrary to rumor, this is not done by back-links.)
Our fundamental visualization shows pages side by side, with visible beams connecting their parts for deep intercomparison. These beams can have various meanings and functions.
Animation of these pages and beams, though not required, is desirable for high-power xanadoc work.
The xanadoc is fundamentally incompatible with the web browser and must be viewed and edited in a different kind of application.
Xanadu has a clean internal design, with as few exceptions as possible, but the difficulty of implementing it has been great.
Mainly because the rest of the world thinks very differently.
=== A DEMO TO LOOK AT
Our latest and best-looking prototype is called XanaduSpaceô. It's on YouTube. You can search Youtube for "Xanadu Space" or go directly to
This Youtube video shows only one of many possible interfaces. However, it shows a main property of Xanadu systems, visible side-by-side connection--
- visible xanalinks (in blue-grey) between portions of content
- transclusions [in pale red] showing contents which are the same-- in this demo, emphasizing the connection of quotations to original content
These connections can in principle be turned off-- made invisible-- to suit the user's needs. But they are always in the structure.
=== THE BASIC IDEA
A xanadoc can have many pages or units. Visible connections may be shown among pages and among xanadocs.
Xanadoc pages can be annotated and connected in many ways, with visible beams showing their connections.
Today's conventional electronic documents are locked to paper visualization. This is often called WYSIWYG, "What You See Is What You Get"-- what you see on the screen is what you get when you print it out on paper. But paper shows no connections.
Xanadocs can't be printed on paper because they do far more than paper can possibly allow. We call our philosophy WYSIWYNC-- What You See Is What You Never Could (before).
This means that Xanadu views and interface are completely arbitrary, unlike today's conventional electronic documents. For instance, in conventional word processing, you have one cursor (or cutting-point) in one page at a time. A Xanadu interface could have multiple cursor positions at once, on one page or numerous pages.
=== === === HOW IT WORKS INSIDE
A xanadoc is represented by
- a list of content portions to bring in from sourcedocs
- a list of overlays to apply to these content portions
The rest is detail.
= THE STEPS
- First the content portions are brought in and assembled as pages or other units.
- Then the overlays are brought in and applied to these content portions. These are links and markups of many types, which may overlap.
- Then the beam connection spans are found by address comparison.
=== === === DATA CONVENTIONS
To adapt to the prevailing world of files, directories and URLs, unusual forms of data have been chosen.
These conventions are counter to the prevailing paradigm, and thus found alarming and crazy by some--
- The content brought in has to be stabilized, with unchanging addresses or designators, so that the same contents are always at those addresses.
- Most Xanadu data structures are never changed or replaced, only appended to. This facilitates re-use and backtrack.
- Change is managed by a document's content list (EDL).
- Xanalinks are applied to the content from an overlay list (ODL). This is sometimes called "standoff markup."
- The individual xanalinks are separately published for reusability.
=== A WORD ABOUT XANALINKS
Xanalinks represent everything which is not in the text itself.
We call our links "xanalinks" to make it clear they are not like weblinks. They are not embedded, they are visible, they can connect more than two things, and they can be of different types.
Xanalinks include the functions of web links and tags, but do much more:
- a xanalink may highlight portions of any document
- a xanalink may make a visible connection between two documents elsewhere
- a xanalink may specify interaction
=== TRANSCLUSION: SHOWING IDENTITES OF CONTENT
When we show content as identical in two places, that is not the linking mechanism; it is done by a very different technique (transclusion search).
=== NOT DISCUSSING OPTIMIZATIONS
There are various simple optimizations we will not discuss here; we are discussing the main mechanism. The system can be optimized in simple ways for sped-up delivery, but the present concern is to present the whole fine-grain concept.
As described here, it allows constant change and simultaneous re-use by all parties, with rich versioning.
=== === === ALSO OMITTED IN THIS OVERVIEW
This is intended as an overview. For simplicity, we are not presenting here--
- any interactive detailingókeystrokes, visualizations, animations-- since there can be many interfaces
- details of the particular data structures
- details of the algorithms (mostly obvious when you understand the data)
- how to manage public and private documents.
- version backtrack and selection (also a simple mechanism)
=== === === MUCH MORE ELSEWHERE
All these technicalities are discussed in our other writings.