xuPurp-D19
=== 13.01.22
XANADU PURPLE OPEN DEFINITION 3
(The filename of this document has been shortened from xuPurple, but the draft number continues to ascend.)
Theodor Holm Nelson, Founding Designer
Project Xanadu
XanaduÆ is a registered trademark of Project Xanadu. TransLitô is a claimed trademark of Project Xanadu.
TRADEMARK POLICY. We reserve the XanaduÆ trademark for our own code and services, and Transliteratureô or TransLitô for the document subset. (We considered making "TransLit" a certification mark, but found that process far too complicated and uncertain.) See below for recommended use of these trademarks for related software.
MAJOR CHANGE from xuPurple-D11: we are dropping the ODL for now, to simplify issues.
=== === === Xanadu Purple (Purp3)-- AN OPEN DEFINITION FOR EVERYBODY
This paper specifically defines a third version of Xanadu Purple (Purp3). It is not final.
(We assume the reader already knows our basic concepts; this enumerates and specifies the current Xanadu design.)
This is an open definition of the current Xanadu software designs. Anyone is free to program to these specifications--
- our document structures (TransLit)
- the user application package (Xanadu Purple).
Xanadu Purple is intended as a stand-alone application and environment. For xanadoc publication, helper servers are also defined.
Xanadu Purple is a simplified version of earlier Xanadu systems, designed to work in today's file and network environment-- without the special servers or addressing of its predecessors, but also without their special search abilities.
UNDERSTANDING THE NAME. Predecessors of this name include--
- Xanadu Green (also known as Udanax Green or Xanadu 88.1), designed in 1979, and still underway under open source at Udanax.com
- Xanadu Gold (also known as Udanax Gold or Xanadu 92.1), designed in 1988-92, and archived at Udanax.com
Xanadu Purple is a simplified and adapted version of Xanadu Green.
= THIS IS A DESIGN; IMPLEMENTATIONS NEED OWN NAMES
"Xanadu Purple" refers to a software design; different implementations intended to follow this design should have individual names, like--
- XanaduSpace
- Xanadesk
- Xanathon
Those names are taken. Naturally, any implementation not by Project Xanadu needs an entirely different name. Any implementation not by Project Xanadu must not include "xana" in the name.
= THE DOCUMENT SUBSET-- TRANSLITô. The designation "Translit" refers to the subset of Xanadu Purple which defines the Xanadu document (xanadoc). We want to assure document compatibility with Xanadu Purple, without regard to methods of creation, publication policies, etc. It is intended to allow people--
- to open and view xanadocs
- to create xanadocs by their own chosen means
- to publish xanadocs by their own chosen means and under policies of their own
Translit thus consists only of--
- document definition
- data structures and file types required for this document definition
Anyone wishing to program a viewer or editor for these documents by any means is welcome to do so. However, you may not call it TransLit. If you want to point out the compliance of your code, we ask you to say instead:
"This is intended to be an implementation of the TransLitô document specification. [and any other comments on compatibility, etc.]"
= THE FULL USER SYSTEM, XANADUÆ PURPLE. The "Xanadu Purple" design refers to our whole package of--
- user application environment (including helper servers)
- breakdown of the software into modules
- data structures and file types
- versioning method
- user content stabilization method (permascrolls)
- publishing method
- allocation of publishing directories
Anyone is free to program to the Xanadu Purple specification by any means, but may not call it Xanadu. If you want to point out the compliance of your code, we ask you to say instead:
"This is intended to be an implementation of [partiular aspects of] the XanaduÆ Purple specification. [and any other comments on compatibility, etc.]"
=== === === TRANSLIT, THE DOCUMENT DEFINITION
TransLit is about a specific kind of document, the xanadoc, built from stabilized indirect content rearranged by pointers. It allows--
- visible connections to origins and re-uses (transclusion)
- visible connections to parts of documents (xanalinks)
Unlike standard documents (.txt, .html etc.), it retains the source identity of all its content. This permits
- going to the original context
- linking to the same addresses by anyone
and much more.
In the distribution form of a xanadoc, all the parts are provided to build such documents by downloading the contents and xanalinks.
HOWEVER, FOR PRACTICALITY, a xanadoc can also be distributed as a fulfilled package. Various combinations of content may be included for stable reference and other reasons. However, the full internal structure needs to be included.
= ID AND TITLE OF THE XANADOC
This is how we identify and refer to a xanadoc.
The xanadocID consists of three fields, the last optional--
- username (should be guaranteed unique somehow; may be an integer)
- docNumber (an integer that does not change)
- microversion [OPTIONAL] (a character string allowing stepping between versions)
The xanadocID identifies a xanadoc uniquely if the third field, microversion, is specified.
If no microversion is specified, the latest version is assumed.
Note that the title, if any, is not part of the xanadocID.
=== DATA STRUCTURE OF THE XANADOC
A xanadoc may be delivered as a fulfilled file (fulfile), or assembled from four internal components, to be explained below--
- EDL
- xanalink
- stabilized content (what the other components refer to)
Stabilized content and xanalinks may be all included, or selectively included, in the fulfilled file.
A xanadoc may for various reasons be delivered without the content. The minimal file that can be distributed, sufficient to build a xanadoc, is the EDL.
= FULFILLED FILE (type .xanaful)-- SEE APPENDIX 4. This sends content and links along with structure.
= EDL (file type .xanedl, .xanadoc) -- SEE APPENDIX 3.
The EDL, or Edit Decision List, specifies the contents (initially text contents) from which to build a document. It is a list of content addresses.
An EDL is likely to change as a document evolves.
= XANALINK (file type .xanalink) -- SEE EXAMPLE AT END
A xanalink is a coupling among spans of stabilized content.
Xanalinks are not embedded.
= LINK TYPES. There may be many link types. To avoid ambiguity, a link points to its type definition as well as its endsets. (SEE EXAMPLE AT END.)
A xanalink has one or more endsets or prongs. Each endset may in turn have any number of spanpointers to content.
A xanalink is a free-standing first-class object which is published as a separate file (if it is published).
Xanalinks, once published, are expected to remain published. A xanalink is removed from a document by removing it from that document's EDL.
=== TransLit USER APP UNDEFINED
TransLit is the document structure. How a user sees or creates this structure is not part of the TransLit specification. (For suggestions, see Xanadu Purple Application, below.)
=== === === XANADU PURPLE, THE APPLICATION-- USERWORLD AND CLIENT
Xanadu Purple is not just a simple text system, but a user environment for creating, studying and integrating xanadocs.
This means holding various structures, manipulating and maintaining them.
=== SCREEN APPEARANCE. We are not specifying appearance here, since we do not simulate paper and thus any possible view is legitimate. (Under the motto WYSIWYNC, What You See Is What You Never Could.)
We have various designs there is no room for here. However, there are several key visualizations we plan--
- side-by-side visible connection (when two xanadocs are connected, or a xanadoc is connected to a conventional document)
- link beams or straps for two-sided links
- propellers for multisided links
- transclusion beams or straps for two-sided transclusions
- propellers for multisided transcusions
=== WHEN IS A DOCUMENT OPEN? The usual tradition goes back to files which are "open" and "closed." A conventional electronic document is either open or closed. However, we consider a document to be open when one one small area of a page is open. This approach will have various ramifications, not covered here.
=== HOW THE APPLICATION TALKS TO THE WORLD
LOCAL. The user has a local computer with screen, keyboard and mouse. Documents appear on the screen and interact.
LOCAL OR REMOTE: SOURCEDOC SERVER. Any sourcedocs which may change are cached here with their time of origin, etc.
REMOTE: PUBLISHING SERVER. To publish, the user has a publication server that is on another machine. The act of publication causes the user's machine to deposit the necessary parts on the publication server and list the new publication.
(For addressing on the publishing server, see Appendix 2.)
=== === === Xanadu Purple open definition: DOCUMENT DATA
Same as for TransLit, plus
- hypertime oplist, registering every edit operation (cumulative)
- permascroll, registering all user input (cumulative)
- caching of content from elsewhere (cumulative)
Functions, operations and conventions to make these work.
These are all discussed elsewhere.
=== === === Xanadu Purple Open Definition-- MODULES
These are discussed elsewhere at lengh.
=== === === PUBLISHING SERVER
We have always planned a Xanadu publishing server. However, publishing may be a service provided by a third party, such as the Internet Archive or Amazon.
Holds a user account's
- EDLs
- links
- cached content [PRACTICAL AND LEGAL ISSUES]
=== === === THE ACT OF PUBLICATION
The act of publication has a number of steps.
- The xanadocID is published (made findable) with its current EDL.
- new links are published
- new content is published
=== CONTENT PUBLICATION AND REDACTION (Xanadu, not necessarily Translit)
User's new content is published as follows:
- The public permascroll is updated
from the private permascroll, unmasking
any newly-published content.
This naturally includes--
- any new published content at the end
of the permascroll
- any newly-published content which was
previously lurking unpublished
at earlier positions in the permascroll
=== === === APPENDIX 1: SERVICES AND POLICIES
The official plan of Project Xanadu has always been to offer offer long-term storage and publishing services.
Xanadu publishing has several parts and concerns, especially long-term availability. (Content stabilization is not a technical issue; it is a policy issue, which is essentially political.)
If others replicate our software, we cannot, of course, control what they do about availability, but they will have to deal with these same policy issues.
=== === === APPENDIX 2: HOW DOCUMENTS ARE ADDRESSED
In our planned Xanadu service, a user account will be represented by a directory, and each document directory will contain
- the EDL of the document
- the links born in the document, each as a separate file
=== TRANSPOSABILITY AMONG SERVERS
(The following conventions allow xanadocs and their contents to be moved among servers, by establishing equivalences among domains and their directories.)
= USER ACCOUNT (a directory with the acccount name)
Example:
WHATEVER.COM/XANADOCS/43/
= SPECIFIC DOCUMENT CONTAINER (a directory)
Example:
WHATEVER.COM/XANADOCS/43/17/
and the document itself will be represented by an EDL within that directory--
Example: the current version
WHATEVER.COM/XANADOCS/43/17/CURRENT.xanedl
(which is interpreted as time of delivery as the current document)
Example: a specific microversion
For a specific microversion, for example microversion 31d14a7
WHATEVER.COM/XANADOCS/43/17/31d14a7.xanedl
= XANALINK
Example:
WHATEVER.COM/XANADOCS/43/17/43.xanalink
=== === === APPENDIX 3: FILE TYPE SPECIFICATIONS
=== EDL, CENTRAL REPRESENTATION OF A DOCUMENT
The EDL (Edit Decision List) is what represents and builds the xanadoc. It is a list of content spanpointers and xanalinks to be assembled into the fulfilled document.
= SEQUENCING OF CONTENT SPANS IN THE EDL
The content spans are listed in the order they will be concatenated.
= SEQUENCING OF XANALINKS IN THE EDL
Xanalinks may be in any order, since they are applied to whatever content they address.
(Xanalinks may be randomly inserted between spanpointers, but this would seem to be poor practice.)
NOTE THAT XANALINKS CANNOT BE DEFINED TO HAVE SEQUENTIAL MEANING. The same set of xanalinks in any sequence must be interpretable in the same way.
= DEMARCATION OF ELEMENTS
To divide these elements and simplify parsing of the EDL, an asterisk begins a new element (spanpointer or link).
Note that an asterisk in conventional text symbolizes a footnote, or connection. Thus beginning a link reference in the EDL with an asterisk makes sense. We generalize this to demarcating content spanpointers as well.
= NAME OF EDL FILE
xanadocID.xanedl
= CONTENTS OF EDL FILE (example)
XANADOCID = xanadocID.microversion
*spanpointer ; OPTIONAL: VERSION WHERE ENCOUNTERED AND TAKEN
*spanpointer . . .
*spanpointer . . .
...
OR [for easy reading]
*transclusion . . . [same as spanpointer, but making it clear that content comes from another document source]
...
*xanalink
*xanalink
=== XANALINK
The xanalink is used to represent--
- any attribute of content
- any demarcaton of content (e.g. page break)
- any relations between contents
- any relations among documents, except for identity (transclusion)
A xanalink is permanently associated with the xanadoc in which it was created; the linkID should be associated with its docid in some way.
HOWEVER, xanalinks are publishd individually as individual files.
On the planned Xanadu server, the link's creator and document of origin are defined by the xanadocID of the folder it's in. However, anyone publishing a xanalink may arrange differently.
= NAME OF XANALINK FILE
xanalinkID.xanalink
= CONTENTS OF XANALINK FILE
XANADOC OF ORIGIN = xanadocID.microversion [MICROVERSION OPTIONAL]
LINK TYPE = whatever
TYPE DEFINED AT = spanpointer
ENDSET 1= e.g. COMMENTED-ON
spanpointer ; OPTIONAL: VERSION WHERE ENCOUNTERED AND TAKEN FROM
spanpointer . . .
spanpointer . . .
...
TYPE DEFINED AT = spanpointer
ENDSET 2= e.g. COMMENT
spanpointer ; OPTIONAL: VERSION WHERE ENCOUNTERED AND TAKEN FROM
spanpointer . . .
spanpointer . . .
...
=== === === STABILIZED CONTENT
Stabilized content is the heart of the system, but this is a pragmatic and political issue. The types below do not affect the logic, structure or coding of the system.
In the planned Xanadu publishing service, there are specific types of stabilized content--
- user permascrolls [discussed at length elsewhere]
- other user-supplied sourcedocs (arbitrary charboxes)
- content from elsewhere, cached and stabilized
How others may publish and stabilize content is up to them.
=== === === APPENDIX 4: THE FULFILE, file type .xanadoc
The fulfile will generalize the EDL to carry content. It will be an aggregated file containing EDL, optionally links and optionally stabilized content, in various combinations for various reasons. ALL CONTENTS AND LINKS ARE ACCOMPANIED BY THEIR STABILIZED ADDRESSES, retaining their original identity.
The suffix .xanadoc is tentatively reserved for this format.
Each spanpointer may or may not be accompanied by its portion.
Each linkpointer may or may not be accompanied by its link.
How to manage these simply in a single file is still a question. (John Ohno has made a clever proposal not included here.)
=30=
span: