T.Nelson
 

"Everything should be as simple as possible.  But no simpler."  -- Einstein
 

PARADIGM I: VIRTUALITY

"Virtual" does not mean, as many think, three-dimensional.  It is the opposite of *real*.

Virtuality therefore means the *apparent structure of things* (and that is what dictionaries have said for two hundred years).

I divide virtuality into two parts:
• conceptual structure-- the ideas and how they interact and unfold, and lodge in the mind.
•• The conceptual structure of a movie is the plot, characters, where set, etc.
•• The conceptual structure of a car is: start, stop, go forward, go back, turn left, turn right.  (Also lights, windshield wipers, etc.)
•• The conceptual structure of software is the space it takes place in and the apparent structure as the user tries to understand it.
• feel•
•• The feel of a movie is the atmosphere, the various moods and qualities.
•• The feel of a car is the handling, the door slam, the color, the smell, the color, the paint job, the trim ...
•• The feel of software is how it looks, how it interacts (crude or slick, smooth or bumpy, highly interactive or with a lot of explanation screens.

Engineers generally deal with constructing reality.  Movie-makers and software designers deal with constructing virtuality.  (The engineers who tune the feel of a car, however, are doing very expensive engineering to achieve the desired feel.)

Software is a branch of movies.

Movies enact events on a screen that affect the heart and mind of a viewer.  Software enacts events on a screen which affect the heart and mind of a user, AND INTERACT.  Much of software is about affecting the heart and mind of a user, and the interaction is an additional dimension to its moviehood.  The technicalities of programming are no more relevant to the design of software than the mechanics of cameras are relevant to designing a movie: providing constraints and tradeoffs, but otherwise largely irrelevant.

I believe that training in film-making is important to software design.

A director integrates all the effects of a film, chooses among many ways to create a specific virtuality.

Training in movie-making is very important for presenting ideas to the heart and mind, and for understanding the technical underpinnings for the feel of things.

The reason that software is still generally lousy is that nobody's directing.  All the little pieces are done independently and not integrated.

The design of conceptual structure

Most people think the conceptual structure of computers is given, since the Xerox PARC user interface (PUI) is the prevailing structure.  But the PUI is an arbitrary mapping of paper.

The design of conceptual structure, separate from any subject, has never been taught.  But there are very few examples, except for the world of games.

The design of ZigZag is therefore an important example for this theory: it is a design of *pure conceptual structure*, a conceptual structure that can be mapped to many different things.
 
 
 

PARADIGM 2: CLOSED WORLD, FLUID WORLD (the Xanadu paradigm)

To be simplistic, there are two ways of treating the world: as closed and hierarchical, or as fluid and overlapping.  There are two ways of treating media: as locked, or as re-usable.

These views affect the way you see life, work, categories, art, publishing, right living.

The locked world deals with closed hierarchical and linear objects.  These are fairly easy to refer to and keep track of, but they badly map what is needed for work, ideas, and changing documents.

In the locked world, you do only one thing at a time.  The name of a project is permanent, and its location on a computer rarely changes.  Thus there is no great inconvenience to naming files, opening and closing them.

In the fluid world, projects, companies and work are constantly evolving and dividing, changing their names and purposes.  Like Rembrandt moving among his paintings you make constant changes to many projects, add notes to many places, rapidly cross-referencing.  The structure of files on computers maps dreadfully to the overlapping structure of work.  And contents move constantly among versions.

In the locked world, documents retain their structure and outline, so very little rearrangement is needed.  The primitive "clipboard" designed by the Macintosh team and not improved in Windows or X, is adequate rearrangement for text documents because so little rearrangement occurs.

In the fluid world, much of the process of writing is rewriting, and rewriting involves massive and repeated rearrangement of contents.  (This was the original meaning of the terms "cut" and "paste", which were redefined by Larry Tesler of the original Macintosh team.)

In the locked world, copyright is being made tougher and more unpleasant, and steps are being taken to reduce the possible re-uses of content.

For the fluid world, we have tried to create a new zone of permission and re-use for on-line content.  Copyright law will continue to exist and the point is to make it as benign and comfortable as possible, with frictionless re-use of contents.

(See illustration: Copyright Castle and Public Domain Ocean)

This has led to the Xanadu model of purchasing digital copies for extremely small payment, with unrestricted recompositing under transcopyright.

This approach treats media as *re-usable under copyright* (through transcopyright).

(Of course, if copyright is eliminated, that part of the system will not be needed.  But meanwhile it is a fair assumption that copyright will continue.)

All this has been the structure of the Xanadu(R) project, now building on the ZigZag(tm) mechanism, has always had a number of goals.
 

Paradigm 3: A MEDIA SYSTEM

ZX is a system of presentation, editing, reference and encapsulation for fluid and overlapping structure quite unlike the other comprehensive systems of encapsulation: Director, Quicktime, XML, RealMedia.

Ours is intended to be an open, principled, extensible alternative for representing everything in a format that is not
• proprietary and foisting an unacceptable model (like QuickTime)
• preposterously complex and tangled (XML)

We need to deal with--
• overlapping and repurposed content
• overlapping projects
• evolving and changing projects and objects
• overlapping aspects of life and work
• exact representation of complex and overlapping structures
• mapping things exactly; or at least representing exactly people's mental models of them
• automatic maintenance of media identities

Those structures must lead to recognizable presentations--
• presentation of corresponding parts of things
•• side-by-side intercomparison of related documents
•• marginal notes on anything
•• overlays on anything
• principled re-use
• identification of all media contents
 

These ideas and ideals have all led to the Xanadu model (see XUmodel.html).

In the Xanadu model (since 1988), we--
• distinguish between content and structure
• separately address CONTENTS and STRUCTURE (not intermixing them, as with HTML, XML, and various proprietary structures)
• allow linking to content (which may be used in different documents)
• allow linking to structure (which may be used in different documents)
• allow packaging of complex objects

HOWEVER. this makes references an order of magnitude more complex.
 
 
 

p.6 ?

DECIDING CONVENTIONS OF WHAT GOES WHERE

ZigZag and ZX are completely arbitrary structures based on interpretable connections.  Working out a system of consistent assignments of meaning is very difficult.

Starting from the principled system of connection, and knowing what meanings we *want* to fit in, we assign those meanings as rationally as possible.

The real issue is designing a consistent arbitrary structure that fits in as much as possible, as comprehensively and comprehensibly as possible.  Consistency, completeness and clarity are the objectives.

We want it to be consistent, to be memorable, and above all to make sense.

But the final design is simply a series of conventions and interpretations of our mechanical space.

There is perhaps an excess of mechanisms, with some uncertainty as to what to use when.  Just as too many words is better than too few, this may be awkward but gives us a lot of options, an embarrassment of riches.  But extra mechanisms don't hurt; they merely create conflict.
 

ZX AND THE OBJECT MODEL

Object-oriented programming has become dogma throughout the computer field.  The ZX model is the opposite of object-oriented programming.

I believe it is time to reconsider OO--
• I believe that object-oriented encapsulation structure is oppressive.
•• You are allowed only the forms of access that the creators want you to have.
•• For media, for example, new uses and new views are paramount-- new uses and views that the creators didn't imagine.
•• I believe there should be direct access to the data.
• OO programs are not reusable unless you adopt the class libraries entirely.

INHERITANCE IN ZX

There are various forms of inheritance in ZX, and more could be contrived.  However, unlike standard OO (where inheritance is between closed encapsulated objects), this is open and fluid inheritance among open structures all of whose parts are accessible.

• Geometric inheritance, esp. with corner lists

*Corner lists* inherit by interpretation of the overhanging elements on one of the dimensions.  This should be extensible to several dimensions.

• Templates, either cloned or interpreted

*Templates* [formerly *clusters*] maintain multiple connections to a set of original cells, to which they are connected on d.template.  Each cell is interpreted by reference to the original template, and the relations of those cells on the original template.  Either special clones of the template, or other cells, are interpreted according to this reference to the original.

In this case, relations are inherited by interpretation of the original elements and their relative positions.

This is very like object-oriented programming: specific cells have faceted meaning within the cluster, and so this passes on the respective roles of the different cells.  It may be used  when the cells are expected to have some specific meaning.

p.7 ?
 

UNITS AND ENTITIES OF ZX ==========

A number of entities and mechanisms have been defined for ZX.  It is better to have too many words than too few distinctions.

These are presented in what seem to me some sort of conceptual progression.
 

THINGS, ITEMS AND OBJECTS

An *item* is a user-significant thing.

A *thing* is anything that EITHER users or ZZ programmers want to refer to.

(I'm not saying "object" in general because of the complex computer connotations of that term-- EXCEPT for flying objects, below, because of the UFO connotations.)

A thing or item may be one cell, a clump or cluster of many, or a plex, or a hyperflob.

CELLS

A *cell* refers to a zigzag cell.

LISTS

ZigZag really consists of multidimensional sequential lists, but it's more useful to talk about structures and spaces that derive from them.

To avoid confusion, if we need to refer to an ordinary piece-of-paper kind of list, I'll say "common list".  (Note that common lists are usually represented in ZZ posward in d.2.)

RANK, HALF-RANK

A rank is a list in a specific dimension; a half-rank is all the cells from the cursor to one end of the rank (including the cursor).  Not applicable if rank is a loop.

ENDCELL

Cell at the end of a rank.

HEADCELL

Cell at the negend of a rank; except for looping cells, in which case the headcell is chosen by the user or arbitrarily chosen automatically.

CLUMPS AND CLUSTERS

A *clump* is a bunch of cells together.

A *cluster* [formerly had another meaning] is a bunch of cells which we want to refer to but not necessarily connected.
 

MEDIA STREAMS
of
S-CONTENTS [term may change; "MS-contents" would be best, for "media streams", but unforch this has certain other connotations]

In today's digital media world, *Contents* accumulate.  In tomorrow's, the accumulation will increase drastically.

In ZX, we simplify wherever possible by distinguishing pure contents (such as text, audio) from packaging and modifications.  These media streams, suitable to be stored on permascrolls, we call s-contents (streamable contents).  We store these s-contents in permascrolls and assign them stable addresses.

In general: text, audio, video, fax, film frames, e-mails... to allow stuff to pile up, while remaining addressable and re-usable in an orderly fashion.

Some things cannot be handled this way: Web pages and their pictures, graphics.  However, where possible we want to *remove headers* and put them in a parallel tag format.

S-Contents include
• text
• audio samples: simple, MP3, etc.
• emails
• faxes (which then become a VERY LONG FAX)
• video with audio (by frame count)
• motion picture footage (by frame count)
• [desirable] VideoWorks animation format
(ancient Macromedia animations, still built into Director)
• [desirable] streaming Flash format (abstracted from the earlier free version of Flash)

It's good to have s-contents of a given type permascrolled together.  However, we can carry this too far: some dissimilar audio formats, for instance, are perhaps best put on the same scroll.

A content link to s-contents adheres to the contents, wherever they may go.

Ownership, rights and permission information may be handled as links.

Note: PARALLEL MARKUP FORMAT

Markup of the SGML type MAY be used with Permascrolls, but should be broken out into a parallel representation under the master numbering address scheme of its permascroll.  See my OSMIC pages; also my paper "Embedded Markup Considered Harmful".

Note: AUTOCAP MODE

For text S-streams, the beginnings of sentences need not be capitalized; capitalization of sentences can be automatic, and allowing the user to leave off the initial capital, *except* for names and other permanent capitals, saves user effort.  This is part of the assumption of constant editorial rearrangement.

TUMBLERS, TUMBLER ADDRESSING

Tumbler addressing is a specific application of transfinite arithmetic discovered by Gregory and Miller (Miller and Gregory, I forget the order), explained in *Literary Machines*.

Permascrolls for different data types and cells should be assigned unit types for tumbler addressing, in order to assure compatibility with Udanax Green (formerly Xanadu 88.1).
 

CONTENT LINKS

Links between vstreams and/or pscrolls.  See XUmodel.html.
 

METADATA *NOT*

In conventional files and Web content, people imagine a boundary between "data" (what they think is the central part) and "metadata" (what they don't think is the central part.  In other words, the term "metadata", as used for conventional files and for Web content, simply refers to *data which is not represented by what they think is the central part*.

In the Xanadu model, there *is no central part*, and so there is no such thing as metadata.
 

DOCUMENTS

A document consists of
• a nameplex owned by the author (including rights & permission info)
• versions consisting of
•• vstream lists pointing to
• s-contents owned by whomever
•• other structures, possibly flobs

STRUCTURE VERSUS CONTENT; DOCUMENTS

In all Xanadu models, there has been a distinction between structure and content, but there have been slight differences among different Xanadu designs as to what was structure and what was content.

In 88.1 and ZX, "Content" (s-content) consists essentially of raw media streams and "structure" consists of the virtual designation of sequences and other mixes of such content.

In 88.1, structure consisted of "links" (xu88 links) were dyadic relations which could in principle be built up to represent any other system of relations.

In ZX, the structure parts of  a document may include--
• ZZ structures
• framing (addressable portions of the document which are not s-content); for example--
•• fields of an email and its cell handles and designators
•• spatial models as parts and pieces of a hyperflob, on which text can be pasted or streamed.
 

VSTREAM

A sequence of s-content portions which is like a stream.  (Same term used in xu88.)

Two examples are prose and simple EDLs.

PROSE

A vstream of text, in general without tags.
 

DESIGNATOR or REFPTRS

A term suggested by Mark Miller for a unit referencing contents or units; especially.  These include--
• handles which reference whole units
• scrollpointers which reference specific stream content

A designator may be thought of as connecting in d.ref to the contents it references (either other cells or permascrolls), although the last step is abstract in d.ref (since the connection to the permascroll is symbolic, in ASCII).

Whether to have only tumblers, or zzcell connection as well, will be a pragmatic decision.
 

PLEX

(Remember that one of the principal objectives of ZX is to facilitate overlapping structures.)

A plex is a user-meaningful structure in ZX.  It ordinarily will contain both structure (represented by ZZ cells), and stream content.  Both of these travel always with their universal ID information.

A plex may also involve other modifications to content (such as audio mix parameter streams).
 

SPATIAL STRUCTURES

A spatial structure is something with spatial coordinates in 2-space or more, but without color or texture mapping.  Spatial structures may be put together to model anything, as components of a hyperflob.

FLOBS AND HYPERFLOBS (multidimensional flying objects) [term may change]

A hyperflob, or multidimensional flying object,

A flob is our standard visible unit in 3space.

A hyperflob, or multidimensional flying object, is a thing which may have coordinates in more than 3D.  (While I hope to avoid the awkward computerish connotations of the word "object" for THINGS in general, this usage of "object" derives from the acronym UFO, and seems exSTREAMly apopropriate.  (Sorry.))

CONTROL CELLS

The control cells of an object are the cells by which it is controlled, esp. handles and other functional cells in its plumbing, such as labels.

PLUMBING

By *plumbing* I mean the mechanisms (and especially dimensional connections) that enact the virtuality of the system-- cell structure to implement a structure or applitude-- not intended to be seen except by sophisticated tinkerers.  The plumbing's visualization is not thought of as a conceptual part of that structure or applitude from the user's point of view.

HANDLE

A handle is the principal cell by which we refer to a thing.  (Discussed in more detail later.)
 

PROGRAMS, ROUTINES AND APPLITUDES; CLANG

(I suppose the terms "program" and "routine" are more or less synonymous; "program" may be substituted for "routine" in the following.)

A *routine* (or perhaps *imported routine*, *external routine*) is a program done in some other language that may be associated with a ZZcell.  A *cellprog* (or perhaps *cellprog routine*) is a clump of cells which have executable functions.

An *applitude* is a set of routines that work together in a way you think of as unified, or for some function that you think is unified.

*Cell programming* is the hypothetical semi-visual programming environment based on ZigZag (see ZZcellProg.html).  (Note that this term is given a different meaning by Softbank, in Tokyo.)

*CLANG* [possibly trade mark, let's not publicize yet] may be a good name for our cellular programming environment.
 

VSTREAM

A vstream is a virtual stream composed of content portions; it is represented by a list of content pointers which represent it.
 

PROSE

Prose is a vstream of text.  It has structure (sequence) but no framing.
 

BUTTERED TEXT / PROSE

Text shown consecutively as if it really exists, even though it is internally a structure of referential designator cells.

Buttering is in ZX a viewing mode.

• Being able to transform back and forth between a cell viewmode and a buttered viewmode can be very beneficial.
 
 

RELATIONS-- A HUGE AREA =============

There are numerous options for representing relations.

• ZZlink

The simple symmetrical vanilla link of ZZ can be given any meaning, which has to be known and interpreted by both users and programs.

The problem arises as we want to indicate multipart relations, multiple relations among the same elements/people, etc.

• ROWS AND COLUMNS to represent relations

Anything you can represent in rows and columns you can do in a zztable, with the additional features--
•• you can skip some columns on a row
•• you can have several cells at an intersection

• SPECIAL CELLS AND SYMBOLS to represent a relation

Where we want typed links, we can represent the relation by an entire cell.  I can't describe this with suitable generality right now; we'll have to look at the example--

EXAMPLE: in my genealogy model, we represent a marriage by a plus or minus sign between first name of husband and wife.  Minus means no children; plus is the negend of a list of children.

Then the children get listed on a column under the relation.
Cloning an individual and listing the clones sequentially works for multiple marriages, whether for divorce or other reasons.

We could extend this to include (suggested contents of relation cell)
• living together (hugely political designation)
•• SO (significant other)?  CV (co-vivant)?
•• Fortunately no need to decide right now.
• affairs
•• @ if no children
•• @+ if children (equiv. to bar sinister)
• gay partner
•• G
• polygamy
•• 1, 2, 3, 4 if wives are ranked (+ if children)
• adoption?  This characterizes not the relationship but the children.  Not sure how to do this SO IT SHOWS EASILY, LIKE THE REST.  Note that a single person can adopt.
• suspect parentage?  "

As with so many other things-- categories and even fictional genres-- it's a question of what we want to represent, and how we want to stretch the structure.

Note that these new symbols would slightly warp the meaning of the "marriage" dimension, but that has go into the documentation.

• CONTENT-LINK to represent a relation

The Xanadu content-link is intended to be used to represent particular relations among content.

• TEMPLATES to represent a relation

A *template* [formerly called a *cluster*] is a designated collection of cells which may be cloned together and whose interrelationship is maintained by interpretation through the relation of the original cells.  Note that this does not have a precise determinate function but rather is a technique which may be used for a number of different purposes, interpreting the relationships of the originals in particular ways depending on the functions of the applitude.

A template may be thought of as a set of faceted relations.
 

• SET OF CODIMENSIONS to represent a relation

For really complex relations, to be viewed in certain ways, you can create a bunch of relations (such as d.version / d..version-set / d..version-alts).

A set of codimensions may be thought of as a set of faceted relations.
 

ULTIDIMENSIONALITY [plz don't publicize this term yet] ===========

The sculptable space of ZX, where subspaces can be constructed of dimensions which are--
• discrete and nonlooping (ZZ)
• discrete and looping (ZZ)
• continuous and nonlooping (Euclidean)
• continuous and looping (whatever we should call that)
• morphs of objects among these
• morphs of spaces around the objects

and Heaven knows what else.  Maybe it's time to lie down.  No, gotta finish this.
 

p.10 ?
 

MULTIPLE ADDRESSES AND IDs of MEDIA

The various kinds of media, including S-contents, will often have many separate indepedent addresses, based on their different re-uses and appearances in different contexts.

These have different degrees of authoritativeness and certainty.

• Example: an email has its serial number (as assigned by sender) and will have another permascroll address.

Potentially vast tables must be kept of these equivalences.  [see my 1995 paper on Xanadu Deep End]
 

HTML BROWSER / CACHE

A related applitude, involving multiple identities of media, answers the question of how to store Web pages.

The whole addressing structure of the Web, and looking at it and saving pages, is a terrible mess--

• A Web page has its URL and current network directories of origin of its component members
• However, cached in the user's browser, these members are given new names for the convenience of the browser, BUT NOT SO THE USER CAN REACH THEM AGAIN!
• In order to see a cached Web page with pictures from various sources, the addresses of the pictures within the HTML must be transposed to their local addresses.  However, this loses track of the original locations.

The ZigZag solution for Web pages and sites is simple: create a zzTable (poss. in 3D) representing both its original location, its cached location, its date and version, etc.
• a row is all the members of a page at a given time
• a column is the members of a given type
• a d.3 rank is the addresses with which to transform a component http request (for example, scanning the original page and substituting the local address for caching).
 

MIME TYPE-- plexes on the march

We want to be able to transmit and keep track of plexes which overlap.

Mime types work with both email and HTTP, which may later facilitate our server and browser mechanisms.

Presumably our definition of an "xu" mime type could be broad enough to work with other Xanadu mechanisms, particularly 88.1.
 

What a mime type will do for plexes--

• sending frozen cells (with absolute addresses)
• sending frozen stream content, with its addresses
• sending their combination.

This means we need--
• ways of referring to overlapping plexes and sending additional cells and content which will--
•• update a plex
•• expand it to contain another bunch of stuff, possibly an overlapping referent package
• hierarchical systems of hash verification (Merkle hash enfilade) and its appropriate mapping to overlapping ZX plexes.
•• This will take some discussions and analyses.
•• since the representation of a cell may vary, the cell rep'zn mechanics should not count in the hash-- so the same cell will hash identically regardless of how represented
 

p.12

GETTING TO THE HOT TEXT VISUALIZATIONS

On another page (ZZviews.html) I show sketches of the kinds of flying-object visualizations of text that we want.  But it will take us several layers to get there.  To build up those text powers, quite a bit of mechanism, and even more explanation, will be necessary.

TEXT IN ZX

Computer people have gotten into the habit of treating text as a "simple" application, with characters treated as individual kernels of corn on a cob.  From this oversimplification we have gotten "text editors", then added fonts and formatting for "word processing", and additional programmers' systems for line-by-line version management-- so complex only programmers can use them.  Worst, embedded tags have become the fundamental model (SGML, HTML, XML), making it all messier than ever.

All of these tools began with a model that was too simple and have resulted in a life that is too complex.

We want something much more powerful amd simple to use, but that does not necessarily mean it will be simple.  (See Einstein quote at beginning).

To implement simple concepts can be quite complex:  Flying.  Rockets to the moon.  Delivery of materials on the Internet.  Mammalian life.  Yet the mechanisms necessary to support these simple concepts are quite complex.

IT IS VITAL TO MAKE SURE THAT ALL TEXT HAS THE SAME PROPERTIES-- whether it is in cells or prose, whether it is in titles or footnotes, or pasted on a 3D shape.  Everything must be uniformably connectable and traceable in the world of documents and versions, so as to follow any text to and from its versions, alternatives, transclusions and links.

If we design such a structure and mechanism to be used at all, then this same structure and mechanism can and should be used for all text purposes.  Then the fundamental data model underneath maintains versions, links and transclusions.

This is the Xanadu model of text.

First it will be necessary to understand the fundamental text structure and link model, which is explained at
https://xanadu.com/zigzag/fw99/XUmodel.html

The Xanadu model is also described in various other places, including my book *Literary Machines*, and most recently "Xanalogical Structure: Needed Now More Than Ever" at
https://xanadu.com/XANASTRUX/XuSum99.html

More detailed mechanisms are described below and later.
 

p.13
 

TEXT MECHANISMS ==========================

Text is the manifest surface of a structure of referential designator cells which point at text permascrolls.

We may flip back and forth between views of the cells and views of the surface structure.

Text may also contain numerical cells and result cells, allowing the direct embedment of any calculation in an explanation of it.
 

PROSE

Prose is strictly sequential as a text vstream and its designator sequence.  (However, it may have tags in parallel format.)

Specifically, a text vstream consists of
• a sequence of refptrs to portions of pscrolls
• (optional) a parallel sequence of tags in corresponding sequence (external tag format for any SGML-type language)
Sentences uncapitalized (rearrangeable autocap format)
 

CONTENT LINKS

A content link follows the Xanadu model, consisting of--
• an addressable unit (the handle, see below)
• a link type designator (another cell)
• *two* vstreams and their designator sequences--
•• the 1-set (term from xu88), or left list
•• the 2-set (term from xu88), or right list

For implementation,
• we select (implicitly or explicitly)
•• the universe of possible links
•• the set of spans within a document whose links are being found
• we then calculate the address overlap of the appropriate spans.

Links may be shown in various ways--

VERSIONS

Versions should be noted on co-dimensions
• d.version
• d..version-set
• d..version-alt
• (I thought I had a use for d..version-list, but now I'm not sure)
 

AN EXAMPLE: EMAIL ===========

Emails are appended into the classical Unix email format (divided by the word "from")

On reception, referential cells are made which point to:
• header
• body
which are further subdivided into cells pointing to fields
•• sender
•• addressee
•• time of sending
•• subject
•• cc:s
and any other fields of interest.
These may of course be stored as internal attributes of the overall email handle cell, which are broken out into proxies if needed to be addressable or commentable.

HOW TO LINK TO EMAIL

We use the Xanadu content-linking model.

For an email E being linked to a comment F, the user
• marks / stripes one or more portions of the email as an addressable span-set
• selects link type "comment"
• types content on a new piece of text, which is appended to user's input permascroll.
 

NOTE: what we do MOST EFFICIENTLY is stripe and multi-select, then move.

Suggested interface: pulling back moves cursor up, trigger starts and stops the intermittent striping.  Could do this with mouse also.

For a threaded mailing list, a participant in the discussion--
• marks / stripes one or more portions of one or more emails as an addressable span-set
• writes a comment
The plex of cells and comment--
• goes out as a mime type
• is attached and presented by the receiving client software
The client software--
• may be programmed by anybody around this structure
• may look any way that legitimately expresses these semantics.

Instead of today's incredibly clumsy devices for following threaded emails, it should be possible to spin around (for instance) a spiral-staircase structure.
 

p. 14

HYPERFLOBS

A hyperflob may have
• one or more vstreams
• one or more spatial structures

The vstreams may be fixed to a spatial model (such as text galley in space), texture-mapped onto a spatial model, or stream through and among spatial models.

*Content links to any vstream in a hyperflob may be called up at any time by the user, selecting that vstream and inquiring about it.*

In the case of the fountain globe, we see
• a sphere,
• two fountain plumes,
• one text streamer saying "NOW IS THE TIME..."
• one rivulet of text
The plumes, stream and rivulet are all be the same mechanism with different parameters-- text associated with a spatial structure and a designated path and velocity.

Each of these units has an associated itemstar, by which the user may see the control cells of the object.
 
 
 

P.16
 
 

HANDLES

Every item has a *handle* or *itemhandle* [term may change].

In order for the handle to be freely connectable and listable in d.1 and d.2, the handle is connected to the item in d.handle.

Example: vstream pointers connect to vstream in d.ref (virtually), handle connects to top element of list in d.handle.

Where to connect the handle to the item is fairly open.  Efficiency question.  I suggest that the handle be connected to a unit at the "upper left corner".  (Negend in both d.1 and d.2).  If a thing happens to have more than one upper left corner, connect it to all of them, at the negend of all of the upper left hand corner cells.

Example.  A list of names and addresses with no title.  It begins with the cells "Abraham | Arthur".  The system detects that "Abraham" is the upper left corner and attaches the handle there.  However, you later decide you want first names first, so you make it Arthur | Abraham.  The system reattaches it.  Then you put in Aardvark | Exterminators and Aardvark becomes the upper left corner, so the system reattaches the handle to "Aardvark".

Surprisingly, several handles of a nested structurte may perhaps be skewered along d.handle.  Consider, for example, the handles of a window with its parameters and the handle of the vstream below it.

CELLWINDOW

Every cellwindow has
• at least one cursor at its center (ideally,
graphically distinct)
• its own cloned subset of the master dimension
list
• at least two current dimensions
• a current direction (not previously
implemented) which defines the direction of
stepping with the space bar
 

GALLEYWINDOW

A zzwindow's handle attaches to the handles of its contents
 

HYPERFLOB

A flying object's handle attaches to a common list (d.2) of the handles of its component pieces.

CONNECTION OF A FLOB TO A PROSEDOC OR VERSION, AND ITS MOTION

d.1=>  handle of object | handle of versionlist | handle of flight/texture parameter list

TEMPORARY VARIABLES OF A
TRAJECTORY
eg billow

TEMPORARY VARIABLES OF A GALLEY
OR WINDOW OR BILLOW
Corner coordinate in space
Pointer to starting position in text (prob. 0)

p.18

CONTENTS AND FRAMING
 

Time as a 4th dimension, WHICH CAN LOOP
(at different rates)

p.19

BASIC OPERATIONS

Includes their keyboard mappings, if significant to me.
"Arrow" means either arrow key or a key from one of the two diamond clusters
 esfc dD ijl, kK (

CURSOR OPS
    arrow

STRUCTURE OPS
• new cell
    N, n arrow
• edit text contents
• clone / transclude cell
    t, T (should also be followd by arrow-- not implemented)
• rename cell
• connect cell
    cellname arrow
• disconnect cell
    b arrow (B arrow not implemented)

• hop
    h arrow (H arrow not implemented)
 

CELL ATTRIBUTES ===== [none as yet
unimplemented]

CELL TYPES
• frozen referential text (the main type)
• result cell
• vink
• clone of any of these types
• multiclone of any of these types (in a cluster)

• time of creation (Unix integer time)
• name of headcell [efficiency hack unless it's a loop,
 in which case the headcell is a designated representative]

Preferred visualization type
•• brick •• pic •• animation (may include sound)
•• Entering animation, if any (may include sound)
•• Departure animation, if any (may include sound)
Preferred coordinate locations

Preflets (at most one per cell per dimension)
• Must-be-next-to  • Must-be-after
• Want-to-be-next-to  • Want-to-be-after
 
 

CREATION, NAMING OF DIMENSIONS
======

A dimension-set ideally has a main dimension with one dot, and other dimensions with two dots beginning with the name of the first.
Examples:
• d.mark
• d..mark-set

By this new criterion, the correct names for the two containment dimensions are
• d.contain (presently d.inside)
• d.contain-list (presently d.contents)
This should reduce ambiguity.

The suffixes set, list and alt-- as in
• d..foo-set
• d..foo-list
• d..foo-alt
we will treat as having particular meanings.  Here is my tentative allocation:

Consider a set of codimensions we might want to make a foo (whatever that may be), and keep track of multiple foo relations.
• d.foo
 is where we will find instances of a foo.  If an item A is to have a Foo, it should typically be connected to A on d.foo.
• d..foo-set
 is used to list the parts of a particular foo.  If a list of things is required to implement a foo, that list should be on d..foo-set.  They do not have to correpond to anything (that would be a different dimension).
• d..foo-alt
 "-alt" is like "-list", but implies that the user may have a choice of several different things.  It allows you to have several *alternative* foos, without being under pressure to decide among them.
• d..foo-list
 might have some other use, possibly to list the names of particular foos.  (I'm slightly confused about this at the moment.)
 

DIMENSION LISTS =============================

d.xxx, d.whatever, d.foo and d.bar are reserved names for documentation.

SYSTEM DIMENSIONS ======
d.cursor

d.clone
d.template
d.template-list
d.mark
d.mark-list

d.result
d..result-list

d.chug

d.ref
d.handle
 

DIMENSIONAL RECOMMENDATIONS

General remark: ALLOCATING DIMENSIONS IS FREEING UP OTHERS.  Since every cell is in all dimensions, to allocate a specific dimension for a purpose does not affect which is not involved in that purpose.

However, allocating a dimension for specific purposes *frees up* the other dimensions which you might otherwise be tempted to use for that relationship.

As throughout this system, trying to make the parts consistent and make sense and be memorable.

- - -

In general: d.1 and d.2 are used for what looks like "paper" in the system.

d.1
Recommended for: • headings, titles of lists • fields of a record, or the equivalent • conventional breakdowns into segments eg •• first name •• last name •• street address •• city •• province or state etc.
d.2
Recommended for: • common lists (no special sequence) • usual list sequences, esp. •• alphabetical order •• chronological order
d.3
Recommended for: scratchpad connection, when you need to connect things without special meaning
d.4
Recommended for: scratchpad connection, when you need to connect things without special meaning

d.comment
Recommended for personal comments on the contents of a cell.
d.documentation
Recommended for *official* (or relatively official) comments.

d.space
*May or may not be useful.  Do we need north-south, east-west?
d.time
Recommended for scheduling.  Can be quite tricky.
d.money
Recommended for keeping track of expenditures, prices, debts.  Detailed procedures not yet worked out.  (Should d.price be different from d.money?)

d.contact-info
 Recommended for connecting names to phone numbers, addresses, etc.
d.personal-info
 Recommended for keeping track of other information about people
d.marriage
 Recommended for keeping track of marriages and living-partners of friends and relatives (or anybody else)
d.children (includes siblings)
 Recommended for keeping track of families and friends' families
 

NON-DISCRETE DIMENSIONS AND PARAMETERS

The designation "d.xxx" has been reserved for discrete dimensions.  For non-discrete parameters, there are a number of choices, such as
• n.xxx
 number
• p.xxx
 parameter
• c.xxx
 coordinate
I see no obvious reason to choose among these, all should work.  Let us think quickly if there is any reason for trying to freeze some meaning for them.

As before, I suggest reserving
n.xxx [reserved name for documentation]
n.whatever [reserved name for documentation]
n.foo [reserved name for documentation]
n.bar [reserved name for documentation]
etc.

Recommendation: we pre-designate either
• n.1, n.2, n.3
• c.1, c.2, c.3
to represent some canonical or basic coordinate-set--
• geographical coordinates
• sculpture or figure defined with some basic origin