sourcedoc: xuPurple-D11

hide references

xuPurple-D11

=== 12.09.24

XANADU PURPLE OPEN DEFINITION (preliminary2)

(We assume the reader already knows our basic concepts; this enumerates and specifies the current Xanadu design.)

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.

AN OPEN DEFINITION FOR EVERYBODY

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 are taken. Naturally, any implementation not by Project Xanadu needs an entirely different 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

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 unique somehow)

- docNumber (an integer that does not change)

- microversion (a character string allowing stepping between versions)

The xanadocID identifies a xanadoc uniquely if a 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

- ODL

- 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 DISCUSSION AT END. This sends content and links along with structure.

= EDL (file type .xanedl, .xanadoc) -- SEE EXAMPLE AT END

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 prongs or endsets. 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 changing that document's ODL.

= ODL (file type .xanodl) -- SEE EXAMPLE AT END

The ODL, or Overlay Decision List, is a list of addresses of the links to be brought in to a document.

An ODL is likely to change as a document evolves.

=== TransLit USER APP UNDEFINED

TransLit is the document structure. How a user sees or creates this structure is not part of the TransLit specification.

SCREEN APPEARANCE. We are not specifying appearance, 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.)

However, there are several key visualizations we recommend--

- 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

=== === === XANADU PURPLE, THE APPLICATION

[STUB]

Xanadu Purple is a text system-- a user environment for creating, studying and integrating xanadocs.

This means holding various structures, manipulating and maintaining them.

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.

=== Xanadu Purple USER ENVIRONMENT

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.

=== 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

[STUB]

DOCID module

new doct

open doct "show document"

step in document

= CONTENT MANAGEMENT MODULE (local, remote or distributed)

It is desirable to have a single module through which all parts of the system receive and store content.

This module is concerned with content flow of contents and content references among the parts of the system.

(The program should be transparent to whether the storage is local or remote.)

The content module receives new content from the user and delivers content as requested by the user.

= CONTENT MANAGEMENT module (stores and retrieves)

- accepts additions/modifications to existing xanadocs

- accepts new documents

- stores new content from user

- stores new sourcedocs brought in by users

= DELIVERY MODULE (responds to requests for full documents or portions)

- xanadocs

- portions of content

- external sources, cached

- user's own permascroll

This should control the--

= PERMASCROLL MODULE (local)

[STUB]

Called by the content management module.

Cumulative storage of user input and redacted delivery.

= SOURCEDOC MODULE (local or distributed)

[STUB]

Caching of sourcedocs

Changeable sourcedocs

=== INTERACTION module

[STUB]

handles screen presentations,

 user input

 and delivers edit ops to other modules

This should control the--

= DISPLAY MODULE

[STUB]

= DOCUMENT PRESENTATION

[STUB]

which controls the

= BEAM DISPLAY MODULE

[STUB]

= SWORFING

[STUB]

= EDIT MODULE

[STUB]

Each edit operation is reflected in the EDL and the screen presentation

insert new or from clipboard

transclude

delete

copy (actually a transclusion)

This in turn should control the--

= HYPERVERSION module

[STUB]

This is called by the content management module.

Oplist/ backtrack, sidetrack

 version ID

Permascroll Module

 -append edit

 

=== PUBLISH/PRIVASH MODULE

opens content from

 permacroll, makes it public

extended and newly- redacted permascroll

 replaces old permascroll

 on publishing site

links go to pub.site

edl, odl go to pub.site

=== PUBLISHING SERVER

This may be a service provided by a third party

If the Internet Archive...

Holds a user's

- EDL

- ODL

- Links

- Doclist [actuallly a xanadoc, with titles transcluded]

- cached content [LEGAL ISSUES]

=== THE ACT OF PUBLICATION:

The act of publication has a number of steps.

- The xanadocID is published, along with its current EDL and ODL.

- new links are published

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

REDACTION

=== === === 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: FILE TYPE SPECIFICATIONS

=== FULFILE (not yet exactly defined)

This is an aggregated file containing EDL, ODL, possibly links and possibly contents, in various combinations for various reasons.

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.

=== EDL

NAME OF FILE:

whatever.xanedl, whatever.xanadoc

CONTENTS:

xanadocID = whatever.microversion

spanpointer ; OPTIONAL: VERSION WHERE ENCOUNTERED AND TAKEN

spanpointer . . .

spanpointer . . .

...

=== XANALINK

On the server, the link's creator and document of origin are defined by the xanadocID of the folder it's in. However, these may also be specified within the link.

NAME:

whatever.xanalink

CONTENTS:

xanadocID = whatever.microversion

LINK TYPE = whatever

DEFINED AT = spanpointer

ENDSET 1= e.g. COMMENTED-ON

spanpointer ; OPTIONAL: VERSION WHERE ENCOUNTERED AND TAKEN

spanpointer . . .

spanpointer . . .

...

DEFINED AT = spanpointer

ENDSET 2= e.g. COMMENT

spanpointer ; OPTIONAL: VERSION WHERE ENCOUNTERED AND TAKEN

spanpointer . . .

spanpointer . . .

...

=== ODL

CONTENTS:

xanadocID = whatever.microversion

spanpointer ; OPTIONAL: VERSION WHERE ENCOUNTERED AND TAKEN

spanpointer . . .

spanpointer . . .

...

=== STABILIZED CONTENT

User permascrolls

Content from elsewhere, cached and stabilized

=30=

raw

span:

References

There are no documents that refer to this sourcedoc.