sourcedoc: PscrLogic-D10

hide references

PscrLogic-D10

=== 12.08.20

PERMASCROLL LOGIC AND THE DUALITY OF ADDRESSING

Theodor Holm Nelson, Founding Designer, Project Xanadu

Xanadu® is a registered trademark of Project Xanadu.

ZigZag® is a registered trademark of Project Xanadu.

The fundamental structure of Xanadu/Translit is simply:

 - portions of unchanging content

 - overlays (standoff markup) for connection and presentation, with many alternative visualizations

This says nothing about

 - how new content is packaged at the time of publication

 - version compare for the author's working manuscripts

Permascrolls provide a unified solution to both of these issues.

=== PERMASCROLLS

A permascroll is an append-only file whose addresses, once written, remain permanent. A permascroll may be public or private, but in this context it is intended as a package for public access to content on the network.

The permascroll methods that follow provide a way of exposing successive new published content to the public. In these methods, the permascroll is exposed to the network (directly or through a utility), continually expanded by successive new published content.

The permascroll concept is not central to Xanadu and not strictly necessary for editing. It is intended as

 - a convention for the packaging of content in successive documents

 - a convenience for authors as their work evolves, e.g. helping them connect and compare their published and unpublished writings.

There are several approaches.

ALL THESE METHODS ARE ACCEPTABLE. The following five methods all fit within the Xanadu philosophy and may be used by different publishing authorities. However, authors may have different preferences.

=== PRAGMATICS OF PERMASCROLLS (MISC. POINTS)

Permascrolls are not needed for documents which have already been published on the network.

It is desirable to have a divider element (such as a bullet character) between entries, especially to help the author peruse the permascroll.

A permascroll is a conceptual entity and not necessarily one file. It may of course be divided for file convenience as it grows (for e.g. the very prolific author or group).

When a segment of private input content goes onto a permascroll, it is only as a complete segment-- terminated by a cursor move or other event; it does not include characters killed by backspacing or overwriting.

=== REVIEW: DIFFERENT METHODS OF CONTENT PACKAGING FOR XANADU PUBLICATION

There are a number of ways we can package up permanent content to accompany a xanadoc.

1. DOCUMENT-SPECIFIC CONTENT PACK (NOT A PERMASCROLL)

METHOD. Put all of the content of a new document into a special file for that particular document (document box, docbox, docuscroll). Put that file on the net, or pack it into a fulfile.

FILE MANAGEMENT FOR THIS TYPE:

- INPUT: writable only by a utility at the time of publication

- AT PUBLICATION TIME: utility writes it as output file.

- OUTPUT: read-only, but fully readable, by the public

2. PUBLIC-ONLY PERMASCROLL FOR AUTHOR OR GROUP

METHOD. As successive documents are published, append all the published source content of an author or group into one public permascroll, establishing the convention of having much of an author's published content in one place. This simplifies re-use and access, but does not retain connection between the author's published and private documents.

FILE MANAGEMENT FOR THIS TYPE:

- INPUT: writable only by a utility to assure append-only, and only at the time of publication

- AT PUBLICATION TIME: utility appends new content to output file.

- OUTPUT: read-only, but fully readable, by the public

3. FULLY-EXPOSED PERMASCROLL.

No one wants this, but I include it here for completeness.

METHOD. All user input is published on the permascroll and therefore published, though when this happens may vary. The user has no privacy of xanalogical content.

FILE MANAGEMENT FOR THIS TYPE:

- INPUT: all user input is written to public permascroll, but written only by a utility to assure append-only. This can be either as created or at publication time.

- AT PUBLICATION TIME: utility appends new content to output file (if not sooner).

- OUTPUT: all content read-only, but fully readable, by the public.

DISADVANTAGE: no privacy for author.

4. BLACKOUT PERMASCROLL (DUAL ACCESS)

This is the simplest permascroll that offers separate access to author and public. Both parties have access to the same structure and address space: the public has access to the public characters, the author has access to both published and unpublished characters. Unpublished characters are blocked from the public, but the position and size of blocked spans can be deduced by snoopy users.

METHOD. Everything an author types goes onto this permascroll, but only the published content is publicly available. The author may see and work with all his typed characters in a common address space, but those which have not been published are not visible to the public. Public requests for unpublished content addresses are not honored, or shown with a blackout character.

MASKING MAP. This is simple to implement and quite straightforward. It is of course done with a masking map of bits or of characters having corresponding positions to the published characters.

DEFICIENCY FROM A PRIVACY STANDPOINT: all addresses (of characters both published and blocked) are visible to the public. The author's input words leave an addressing footprint; users can see the addresses of blocked private content.

Some may find this unacceptable, others may find it unimportant.

FILE MANAGEMENT FOR THIS TYPE:

- INPUT: written by utility following private user input, either continual (deprecated) or at publication time

- AT PUBLICATION TIME: (Easiest) go through all the characters of a newly-published document and flip them all to Published status, not bothering to check whether they were already published

- OUTPUT: Data cannot be directly accessed. Delivery is managed by a daemon that delivers--

 -- to the author: any characters

 -- to the public characters known to be published. What it returns for blocked characters is to be decided; probably a nonsense character rather than a parsed delivery message.

 

5. DOUBLE PERMASCROLL, PRIVATE AND PUBLIC

This is the best solution but the most complex. It maintains the privacy of unpublished content AND its addresses.

METHOD. User input goes to a private permascroll with private addresses. At publication time, content is given public addresses, and links to that content are converted to its public addresses.

A coupling-function maintains correspondence between private addresses (which the author may continue to use) and public addresses. If the author happens to use public addresses to his own published content, the system should have no problem.

THE EDITING SYSTEM. As the author continues to work, equivalences between internal permascroll and external permascroll are kept seamless for the author. This allows version compare and later publication of adjacent other material.

FILE MANAGEMENT FOR THIS TYPE:

- INPUT: author's input goes to private permascroll with private addresses.

- AT PUBLICATION TIME:

 -- utility assigns EXTERNAL / PUBLISHED addresses to the formerly private, newly-published content and appends it to a published permascroll, with these new public addresses. Utility resets all private addresses of published links to these public addresses.

- OUTPUT TO PUBLIC: daemon delivers published characters by external addresses. Public permascroll is read-only but fully readable to public.

- OUTPUT TO AUTHOR: daemon delivers unpublished characters by internal addresses, published characters by external addresses OR internal addresses.

=== === === DUALITY OF ADDRESSING, A PROBLEM

The double permascroll requires the author's editing system to recognize both addressing schemes and their equivalences-- internal addresses and exernal addresses combinable freely and always equivalent.

There are a number of strategies for this dual addressing, but they are technical and we need not discuss them here.

ZIGZAG DUAL ADDRESSING

A dual addressing scheme also comes up in ZigZag designs, between the cellular level and the text level. (See my email of 12.08.19, ":zz,xu,jjsp: [REV.] Unifying ZigZag and Xanadu with zz textpointers".)

However, the solution proposed there (a special dimension) is not relevant in the Xanadu/translit context, since Xanadu/translit is fundamentally independent of ZigZag dimensions.

=30=

raw

span:

References

There are no documents that refer to this sourcedoc.