Theodor Holm Nelson
Oxford Internet Institute and Project Xanadu
electromail address grebnetug[å]xanadu.net

        Note: Your questions and emails may be posted.
        Note: We are looking for a coordinator, one person who can understand all the details and explain them to participants.  Repeatedly.

---

* "Transliterature" is trademarked not for commercial purposes but to avoid semantic creep. Our trademarked terms may be used only for what exactly fits our specs-- with no additional features.  (Software compliant with our specs but having additional features may be called Transliterature-compliant.  [To be detailed in open source license not yet decided.]  The same applies to Transquoter, TransLit, LUSTR, Transversioner.

Note that for trademark purposes this Transliterature design itself counts as goods distributed in commerce.

|

This work derives from a simple question we asked long ago: "How can computer documents shown interactively on screens, stored on disk, transmitted electronically improve on paper?"  Our answer was: "Keep every quotation connected to its original source."  We are still fighting for this idea, and the great powers it will give authors and readers.  (Others would later ask a very different question: "How can computers SIMULATE paper?" the wrong question, we believe, whose mistaken pursuit has brought us to the present grim document world.)

One part of this project is available already: The Xanadu® Transquoter, which does indeed keep quotes connected to their origins.
 

To laymen and outsiders, the world of computer media seems immutable.

You have been taught to use Microsoft Word and the World Wide Web as if they were some sort of reality dictated by the universe, immutable "technology" requiring submission and obedience.

But technology, here as elsewhere, masks an ocean of possibilities frozen into a few systems of convention.

Inside the software, it's all completely arbitrary.  Such "technologies" as Email, Microsoft Windows and the World Wide Web were designed by people who thought those things were exactly what we needed.  So-called "ICTs"-- "Information and Communication Technologies," like these-- did not drop from the skies or the brow of Zeus.  Pay attention to the man behind the curtain!  Today's electronic documents were explicitly designed according to technical traditions and tekkie mindset.  People, not computers, are forcing hierarchy on us, and perhaps other properties you may not want.

Things could be very different.

Instead of looking at deeper possibilities for electronic literature, the designers of today's electronic documents have imposed hierarchy and simulated paper.  This has drastically limited us.  We cannot annotate, we cannot publish side-by-side commentaries, we cannot legally quote at length, we cannot easily see the original contexts of quotes.*

* I must concede that there are many disparate attempts to do these things, and others mentioned later, but the increasing tangle of today's systems probably dooms most of them to only local success.

All this the Transliterature Project wishes to change.
 

How about--

allowing any two documents or versions to be compared side-by-side, showing their links and/or transclusions (if any).

allowing anything to be annotated side-by-side by anyone, attaching comments to any document and publishing them.

keeping quotations connected each to its original context, viewable side by side; facilitating the legal re-use of content (method and permission for doing it)

permitting profuse and varied links of many types by different authors, overlapping freely

shared workgroup writing-spaces where different contributions are recognizable

allowing alternative views of the same document

allowing easy management of many simultaneous versions

allowing user choice of views and interfaces

and much more.

We believe many people have yearned for such capabilities but haven't figured out how to do them.  It's by no means obvious; we have worked on the problem for a very long time, and propose a simple generalized method.

To be sure, for each of the objectives I have enumerated, there is someone trying to do it on the World Wide Web.  But such efforts must perforce be entangled with web methods, designed for other purposes, and so they tend to be limited, incompatible, and hard to use.

We believe now is the time to start over.

BETTER TOOLS

To satisfy deeper literary needs, we want to provide a deep new system for editing and rich document management.

Instead of the "clipboard," which loses all identity of its contents, we propose pullacross editing, where the user pulls a portion from some source and carries it visibly to its new context.

We further intend that you can continue to see, at any time, where each portion came from--

We also generalize to new forms of document.  Think of generalizing the magazine layout, for instance--

The magazine layout isn't about paper.  It's about showing related parts interestingly.  The magazine layout deconstructs into related parts which can  be seen in new spaces.

Generalizing this even further, we hope to provide new kinds of hypertext the world has never seen (flying and floating), doing and showing far more than can be done in today's documents.

We should be able to fly documents in 3D gaming space (using today's incredible gaming graphics)--

With transliterary data structure, however, all this can be linked to any degree, and show origins of each portion as well.

As a system of on-line publishing, this should present a real alternative to the World Wide Web but interconnectable with web documents.  (We can point at theirs and vice versa.)
 

Tekkies think that electronic documents and the World Wide Web are something completely new and that they own it, exactly the way every generation of teenagers thinks they've invented sex and it's their secret.

But it's not new and they don't own it.  Word processing and the World Wide Web are not intrinsically new.  They are literature.

What is literature?  Literature is (among other things) the study and design of documents, their structure and connections.  Therefore today's electronic documents are literature, electronic literature, and the question is what electronic literature people really need.

Electronic literature should belong to all the world, not just be hoarded by a priesthood, and it should do what people need in order to organize and present human ideas with the least difficulty in the richest possible form.

A document is not necessarily a simulation of paper.  In the most general sense, a document is a package of ideas created by human minds and addressed to human minds, intended for the furtherance of those ideas and those minds.  Human ideas manifest as text, connections, diagrams and more: thus how to store them and present them is a crucial issue for civilization.

The furtherance of the ideas, and the furtherance of the minds that present them and take them in, are the real objectives.  And so what is important in documents is the expression, reception and re-use of ideas.  Connections, annotations, and most especially re-use-- the traceable flow of content among documents and their versions-- must be our central objectives, not the simulation of paper.

Those who created today's computer documents lost sight of these objectives.  The world has accepted forms of electronic document that are based on technical traditions, and which cannot be annotated, easily connected or deeply re-used.  They impose hierarchy on the contents and ensnare page designers in tangles only a few can manage.

"Technology" must no longer be the emphasis, but literature.  "Hypertext"-- a word I coined long ago-- is not technology but potentially the fullest generalization of documents and literature.  Text on paper was the best way to present ideas in the paper era, when there was no other way; but now we see fantastic movies and commercials to imitate, and we have super-power graphics cards that can enact swoops and zooms hitherto scarcely imaginable.  Tomorrow's true hypertext can give us far more powerful ways to show, integrate and embellish ideas-- leaving behind the imitation of paper represented by word processing and the web.  It's time for a new flying cinematic literature to represent and present tomorrow's ideas.

(Indeed, if we stop imitating paper, the long-doubted "paperless office" may still be possible :)

 

The design of electronic documents is not "technology," dictated by necessity like plumbing or aerodynamics. It is design, a system of conscious decisions about the way things should be-- like architecture, music or game design. The design of our electronic documents has shaped today's world. And so far it has been simpleminded, shallow and darkly limiting.

What follows is not a promise but an agenda and a fairly complete sketch.  It has no delivery dates.  It could take decades or it could take months, depending on who else cares.  It may not happen in my lifetime.  But the important thing is to start.

"Transliterature" is our name for a proposed new universal genre intended to unify electronic documents and media, erasing format boundaries and easing the copyright problem.

It is an extremely simple design, intended to correct many things that are wrong with today's computer world and liberate our use of media.

It should make possible a new crossover medium-- transpathic documents-- allowing you to step from content in one document to the same content in another document (which could be a movie, or radio show, or new media construction).  This should bring new insights, new forms of anthology, and new forms of copyright and media commerce (see Transcopyright.org).

Underneath, Transliterature uses a method of open media packaging (LUSTR), described below-- an extremely simple new infrastructure.  (Reviewed and summarized at end.)
 

What follow are not small objectives, but the steps are relatively small and the methods simple now.

We want to provide a principled alternative to today's electronic formats and enclosed, canopic-jar document conventions.
We want to show far deeper hypertext than is possible on the web.
We want to unify hypertext with word processing, audio and video, email, instant messaging and other media..
We want to offer a principled new form of rewritable, reworkable content.
We want to make the processes of work simpler and more powerful.

NEW FORMS OF RENDERING AND INTERACTION

Rendering, or actual presentation of the document, is not locked to a particular view, as in today's tradition of paper simulation (WYSIWIG, on which most current formats are based).

Fundamental view: Parallel tracks.  At all times a multitrack view is to be available, showing the virtual media stream(s) and their parallel relations of link and transclusion.  This multitrack view is to be the basic transliterary view, in the same way that a paper-simulation view (WYSIWYG) has been the basic view of today's conventional electronic documents.

Multitrack views are already familiar in many contexts, e.g. audio editing, parallel timelines.

Game-space views.  Using such mechanisms as 3D and Flash, we can show documents in many radical new ways, including flying islands, crawls, escalators, Matrix rain, etc.  (We call this WYSIWYNC, What You See Is What You Never Could-- before.)  All content so presented remains subject to profuse link and transclusion following.

Multiple views.  Authors may recommend more than one view of a document, and users may override the author's recommendations.  (We call this pringiple WYSIWYL, What You See Is What You Like.)  You can of course simulate paper if you like; paper simulation can be just one among the available views.  It should be possible to show and print transliterary documents in the conventional ways, simply returning them to the selfsame legacy viewers from which they were received.
 

Links to and from all portions of a document must be followable, as well as transclusion paths to origins (transpathic connection). Transpathic stepping to the original context, or other currently resident document, must be possible.

Since we want to make possible many or myriad overlapping links (impossible on the web), there need to be ways to riffle through them interactively.
 

Unlike most other document representations, transliterature is simple and transparent, based on the open parallelism of contents, markup and connections.

It may be to a degree obsolescence-proof, in that certain basic structures can be permanently settled and always visible on request.
 

The Xanadu Transquoter, explained at "Xanadu Transquoter in Brief," may be downloaded and used to create indirect (referential) documents, where every portion is transpathically connected to its source.  The Transquoter is effectively our invitation into the larger transliterary system.

We are hoping that competent and compatible people, feeling inspired, intrigued or amused by this alternative universe, will show up and join in.

A NOTE TO THE HUMANISTS WHO HAVE TO STOP HERE

What follows has to be technical.  But to those humanist readers who care about these issues we say: this will require new editing and viewing programs and a good deal more.  It could be done in months if we had resources, or it may take years or decades.

if successful, this should make linking and annotation of any screen documents easy
if successful, this should make deep quotability easy and widespread (for a preview that already works, see the  Xanadu Transquoter), expanded further in "The Xanadu® Transquoter in Brief".
if our copyright idea catches on, this could create a growing pool of legally re-usable content, always brought from each respective publisher.

Thank you for your support.

Now, for Those Who Are Technically Knowledgeable and Open-Minded--
INTERNALS OF TRANSLITERATURE

  

It is important to understand that these internals  should not be seen by most users.  With proper  software for editing and presentation,  Transliterature should be as easy to use as any  conventional document system.

 

These methods may seem complicated and unnecessary   if you lose sight of what they accomplish.  The overhead   may best be compared to the huge headers of email or  the trillions of lost packets on the Internet or even our  dark DNA seeming inefficiencies, hidden from our eyes,  that make a great deal possible.

  

WHERE TRANSLITERATURE CAME FROM . This is an adaptation of the reference version of the Xanadu® hypertext system (xu88, now "Udanax Green"), designed by Roger Gregory, Mark Miller and Stuart Greene.  I have made numerous adaptations to present-day conditions, including the exposure of conventional files, adaptation to current forms of addressing, and deconstruction of ambient formats.  (I have had to drop the more powerful and obscure features, such as permutation matrices of transfinite span addresses, so only one-level transclusion is supported.  Not to mention enfiladics.) Meanwhile, Roger Gregory says the Green server has been debugged.  Jeff Rush says he has converted it to Python.  We look forward to merging these efforts.

Transliterature is the system of documents; the program to run it is to be called TransLit.  TransLit is to be a client program, almost entirely carried out in users' machines, but with server boosts welcome--

- especially from the EPrints portion and context services, discussed in "The Xanadu® Transquoter in Brief").

- from the Transversioner, a generalization of Ken'ichi Unnai's implementation of the hypertime editing design (ca. 1996).

Keeping the core functions in the client may help somewhat in a number of copyright issues (though we offer a generalized solution for the on-line copyright problem; see Transcopyright.org.)

TRANSLITERARY INTERNALS:
LUSTR (Level of Universal STRucture)

This brings us to the general design for the transliterary data system.  (LUSTR, Level of Universal Structure.)

It is not heirarchical and not encapsulated.  It consists of addressable content streams and structures to be applied to them.

|

 

A transliterary document consists of a list of selected content  and a list of selected clinks.  The content and clinks may be brought from anywhere. The content is brought in and the clinks are applied to it. Content elements are individually addressable and clinks  are individually addressable.    With this you can do anything.

The transliterary internals are extremely simple and minimalist but very different from conventional methods.  Once you understand the data structure, the mechanics become relatively trivial.

The transliterary document is inside-out from a conventional document (such as a textfile or a web page).  Instead of a document being a lumpfile of content and markup, it is maintained as a list and fulfilled in the client, which sends for the contents, the connections and markup.

Essentially, we assign stabilized network addresses to all text (later, other fluid media-- audio and video, instant messaging, persistent streaming, etc.).  For instance, we obtain the indexed positions of a web page through Andrew Pam's algorithm.

Then we deal with the content indirectly, referring to it at all times by these stabilized addresses-- with referential editing*, markup, delivery and packaging.  That's all there is to it.  However, God is in the details.**

* Note: Bill Duvall, an alumnus of both Doug Engelbart's NLS group and Xerox PARC, told me recently that he had actually tried referential editing on the Alto, based on my proposal for referential editing decades ago.  As I understand it, Bill implemented an NLS lookalike on the Alto as an experiment-- the full instruction-set of Doug's system.  However, it was referential like Transliterature, manipulating pointers to cumulative text.  He was surprised that it actually ran faster than the native NLS!  (It should still be available on somebody's Alto disk, he thinks.)

Speed was never the point; the ideas behind referential editing were interconnection and backtrack and structural clarity.  But this is a fine little piece of history.

** I believe this was the original Shaker motto in the nineteenth century, but somehow it has been assigned to another Being in recent usage.

Then we apply markup and structure (clinks) as external pointers to the content.

This approach is counterintuitive, and powerful, and in principle can solve many issues of linking, versioning, copyright, origin.
 

Conventional electronic documents are direct, carrying the actual text (and other media contents) inside some packaging file (.txt, .rtf, .pdf, .html, etc.).

A transliterary document is indirect, meaning that we edit it and distribute it as a system of pointers.  One kind of pointer (the content pointer) brings in a span of content, another kind of pointer (the clink) attaches or decorates contents.  They are internally similar, but have very different functions.

A transliterary document uses conventional documents as a source pool, as well as permascrolls-- cumulative files which have not been arranged into presentable documents.  (See "Transliterary Content Game.")

Within the transliterary paradigm, the main act of publication is to distribute an indirect document by sending out a package of these pointers, called an EDL (Edit Decision List).  Any new contents to be included need to be put out on the net first in source documents or permascrolls, so they too can be pointed to by the EDL.  Otherwise the chain of uniform reusability will be broken.

---

We will first discuss the content list (part of the EDL) and how it is edited.

Detailed Examples of Document Representation, Editing, The Transclusion Operation

This section is intended to clarify key issues of indirect document structure to those who are interested.

Many find the transliterary approach totally counterintuitive.  People have many vital questions about transliterary structure-- especially indirect documents and editing.  It makes no sense until various questions are answered.  The following examples should clarify most of the basic issues, and clear up the common misunderstandings, about transliterature.

We will first discuss the EDL without clinks.

We will look at small-scale examples, trivial by themselves, intended to illustrate technicalities which will be useful with more significant content portions.

You may want to install the Xanadu® Transquoter to study these examples.

If you want a quicker read, you may be able to follow the examples anyway.
 

Understanding requires examples.  In what follows we will indicate

The fundamental operations, demonstrating on plain textfiles (using the Xanadu Transquoter)--

rearrangement
insertion of new content
deletion

The extended design of our structure as an alternative for decorated and connected text (such as HTML)--

how 'tags' can be converted to clinks
how clinks work with content

We will use the Transquoter, which already handles plain text according to the transliterary principles, as a client program that assembles an indirect document into a web page.  (But because it works in a web browser, it is much more limited than the Transliterature design.)  It has its own special adaptations particular to the web browser; see www.translit.org/transquoter/.  But it can be put to good use demonstrating the fundamentals of our approach.

Let's take some examples.

Let us use the following classic text, widely known to typists and journalists, because it compactly uses every character of the English alphabet.

THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG

For use in our exercises, we have stored this all-caps textfile at

transliterature.org/tlitExx/QUICKBROWNFOX.TXT

First let us send for its contents with an EDL.  We put the following spanpointer into a .EDL file and send it to the Transquoter.  (I.e., if using Windows, we put it in a textfile, change the suffix to .EDL and double-click on it, or drop it on the Transquoter code.)

transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:0/44

This opens the content text in a browser.

So far not much.

The text happens not to have any markup, but even if it did the result would be the same, since the Transquoter strips markup from web pages.

Now let's put our fox to work.

  

It is important to keep saying that Transliterature is in  pre-prototype. Eventually users should see an "ordinary"  text editor.   Indeed, it could be an ordinary editor with  an output option to transliterary format. However, the internal results of all editing are indirect  (virtual, referential), maintained as content lists.  Thus  we work with and maintain the document principally as   a content list and clinks (to be discussed).

.

Let's see what this indirect editing looks like internally.  We'll rearrange the above textfile indirectly into

OVER THE LAZY DOG JUMPS THE QUICK BROWN FOX

Let's create an EDL that will rearrange it referentially.

Here are three span URLs, pointing respectively to "OVER THE LAZY DOG ", to "JUMPS", and to "THE QUICK BROWN FOX", with appropriate spaces included.

transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:26/19
transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:19/7
transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:0/20

If you have the Transquoter installed in Windows, you can make an EDL of these spanpointers.  (Put them in a textfile, change the suffix to .edl.)

Now click on this .edl file, causing Windows to send the EDL to the Transquoter.  See if you don't get--

OVER THE LAZY DOG JUMPS THE QUICK BROWN FOX

(If you don't have the transquoter installed, you'll just have to trust us :)

ADDING NEW CONTENT

What if you want to add new content?  Let's substitute the word "purple" for "brown" in this example.

Since we don't change the original document addresses, we have to put the new word somewhere else.  We could append it; as it happens, we've put it in a document called InputPermascroll, which we'll assume is a place where you keep putting your text additions.  (Note that this should be done automatically by a proper editor.)

Here's the same story, but now the fox has changed his color.

 

transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:26/19 transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:19/7 transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:0/10 transliterature.org/tlitExx/InputPermascroll.txt?xuversion=1.0&locspec=charrange:16/7 transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:15/4 We will refer to this as "the purple EDL" for future reference in later examples.

When we put these into a .EDL file, the Transquoter delivers the desired

OVER THE LAZY DOG JUMPS THE QUICK PURPLE FOX

which remains connected to its original sources, as before.  Note that only "purple" shows a mouseover color, since the others are from the first document transquoted; by default the first document put to the Transquoter in the EDL has no mouseover color.  (See transliterature.org/transquoter/.)

DELETION

Deletion doesn't actually happen, in that no content is changed; we simply change the EDL to ignore that content.  Content left out of an EDL is effectively deleted.  "No implementation is required," except the editing operation to change the EDL.

Example left to the reader: try deleting "purple" using the above EDL.

THE UPPER-AND-LOWER CASE PROBLEM

So far so good.  Textfiles like that, made of all-cap text, are comparatively easy to rearrange.

Unfortunately we run into problems with upper and lower case.  If we do the rearrangement above with a sentence that has normal upper and lower case, what happens?

Take this original (the same story, but no longer all caps)

The quick brown fox jumps over the lazy dog.

which we have stored at transliterature.org/QuickBrownFox.html.

Now let's rearrange this document in the same way we did with the raw uppercase textfile.  Because of our web-page analysis algorithm, the counts required in the span URLs are the same as for the same exercise on the textfile.  Here is the EDL:

transliterature.org/tlitExx/QuickBrownFox.html?xuversion=1.0&locspec=charrange:26/17
transliterature.org/tlitExx/QuickBrownFox.html?xuversion=1.0&locspec=charrange:19/7
transliterature.org/tlitExx/QuickBrownFox.html?xuversion=1.0&locspec=charrange:0/19
transliterature.org/tlitExx/QuickBrownFox.html?xuversion=1.0&locspec=charrange:43/2

This presently gives us, with the Xanadu Transquoter,

over the lazy dog jumps The quick brown fox.

Ooops!  Upper and lower case aren't changed automatically, are they.

We'll deal with that later on, but not with the Xanadu Transquoter.  In the larger Transliterature project we intend to use mechanisms (clinks) that leave the Transquoter behind.  (See later in this document.)

  

Highly technical point for our old friends-- THE EDITING MECHANISM FOR TRANSCLUSION:  No Recursion. There has been considerable confusion as to what happens internally  when you transclude from one EDL to another.  It has been widely imagined  that somehow our method keeps track of where the URLs have been.   It does not.  Many people have gotten the impression that we must search  successively through every document that a content list has passed through.   This is not the case. Let's take an example. Suppose we take the previous rearranged brown fox example  (generated by the Purple EDL)-- OVER THE LAZY DOG JUMPS THE PURPLE FOX Now suppose you want to create a document transcluding the phrase  from the previous example, THE QUICK PURPLE FOX, so it will retain  its connections to its origins.  You want your new document to say I look forward to meeting THE QUICK PURPLE FOX. Now let's say you append "I look forward to seeing" at  transliterature.org/tlitExx/InputPermascroll.txt. Now your EDL simply copies spanpointers from the old EDL.   The result takes each content portion from its source, as before. To transclude content-- in this case THE QUICK PURPLE FOX,  which already took three span URLs-- you copy the three span URLs  already used. Your new EDL simply gets spanpointers from the previus EDL.  The resulting EDL: transliterature.org/tlitExx/InputPermascroll.txt?xuversion=1.0&locspec=charrange:192/27 transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:0/10 transliterature.org/tlitExx/InputPermascroll.txt?xuversion=1.0&locspec=charrange:16/7 transliterature.org/tlitExx/QUICKBROWNFOX.TXT?xuversion=1.0&locspec=charrange:16/4 Each portion of the URL is taken from its original source; we do not  pass through the intermediate file. (If we were transcluding only part of a portion specified by one span URL,  the parameters would of course have to be adjusted.)

---

FIRST, THE ISSUE OF REPRESENTATION

We want to deal with more complex formats-- not just upper and lower case.  If we add all the features and aspects that we want text to have, however-- fonts and footnotes and links and so on-- things get more complex.

The response of the computer community to this problem has been the baroque embedded formats of today's document world, incompatible and generally incomprehensible without months of study.  We think the following plan is simpler and also will allow us to do much more.

The transliterary alternative is to put these formatting structures outside the content, yielding a simple structure.  The basic unit is what we call the Content LINK or CLINK.*

SEARCH:

Related searches:
document content should editing design

gipoco.com is neither affiliated with the authors of this page or responsible
for its contents. This is a safe-cache copy of the original web site.

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.