sourcedoc: zzSpecMin06-D7

hide references




For Those Who Know Already

        Theodor Holm Nelson, Project Xanadu(R) and Operation ZigZag

        TRADEMARKS: Xanadu(R), ZigZag(R) and the Eternal-Flaming-X Symbol are registered trademarks. The ZigZag Logo is a claimed trademark. The following are claimed trademarks: CosmicBook, FloatingWorld, LifeDimensions, and others.

This is intended as a very brief statement for those who understand most of these matters already but would like to see all the details in one place. It is an off-the-cuff cutdown of two enormous documents, zzMain and zzDims'n'Slices.

I'll use two notations to prioritize--

    *(asterisk-parens) for less central designs, or those not yet implemented

    **((double-asterisk-parens)) to indicate undecided issues not currently planned in.


Zzstructure is something I discovered/invented, a simple abstractive generalization of lists and tables,

Zzstructure is a fabric or mesh representation that can in principle subsume

    - entities

    - relations

    - attributes

    - hierarchies

    - objects

    - databses

    - lists

    - pointers

and other discrete structures of the computer world.

Everything is a cell, a connection or a construction of cells and connections.

Zzstructure is built of cells and links, nothing more. Combinations of these structures build everything else. This is to maintain a bottom-level simplicity that can always be viewed clearly. Complexity is relegated to combinations of these structures.


    - a cell is in principle an untyped unit of information.

    - links are reciprocal/symmetrical, but have defined directions. Each link is assigned to a dimension, which determines

        -- how the link may be viewed

        -- which other cells and cellfaces it may be connected to

        -- how certain cells may behave or be operated on

    - there are no link types

    - there are no many-to-1, 1-to-many or many-to-many connections

    - all lower-level cells hold only one data type

That's all there is to basic zzstructure. I think. (This can be further axiomatized, but not now.)

    Note that these last principles three maintain the low-level simplicity of the system. Those who object to these last three principles should note that they can be seemingly overcome by new views and structures: if they want link types or many-to-one connections, they can be simulated in zzstructure and made to appear as desired in new views.


With zzstructure we may build fabric or mesh representations (i.e databases) that are extremely flexible.

    - fabric as an alternative to hierarchy

    - loose data mesh is good for irregular information

    - no space is wasted in missing information

    - able to continue operation while being radically changed (no need to stop and debug, as with relational database)

and having various other advantages.


The following are zzstructure configurations (which we have no time to explain in detail) that have interesting properties (which we have no time to enumerate here). These configurations may in turn be built up into larger structures.

    - corner list

    - twisted ranks

    - loose table

    - monotonic loose table (perhaps the simplest data mesh)

    - twisted table

    - wheel, wheelplex

    - oklahomic, oklahomic wheel

    - hopflag (cell which hops across a rank; its position represents a binary choice)

    - rank intersection (may be plurality of cells)

For repetitive data:

    - starburst for repetitive data (vs. loose table)

    - zzcule (may be assembled into zzcrystal)

And a variety of others.


Zzstructure invites many visualizations, dimensional assignments, operations and constructs. However, none of these are intrinsic to zzstructure. Adding these makes it a particular instantiation or build-out of zzstructure.


ZigZag is my own build of zzstructure, colonized into a data system and user environment, possibly an OS kernel. Zzstructure could of course be built out many other ways. However, I am eager to get product to market and these are my choices.

I am trying to optimize this design for breadth of functionality. It involves many decisions, neither right nor wrong, on different issues. Thus no design decision is in itself right or wrong, except as it contributes to a compact and well-rounded whole.

(CosmicBook and FloatingWorld are my current designs for documents and a viewing space, built on ZigZag. They will not be discussed here.)


Where possible, we maintain all relations in the system by direct connections: it is possible to specify cells, operations and cursors by connecting to them with other pointer cells on various dimensions. Thus cross-references do not need additional variables. This turns out to be compact and clean.


The geography of ZigZag has to do with pre-supplied cells and their arrangements, especially for data structures and docking. Each slice has a home cell. On slice 0 the Home Cell is at the end of Main Street (+d.1) and has Park Avenue running through it (d.2).

The clockwork of ZigZag is the system of geography and wheels used to keep track of things. This includes various list positions where lists will be built and unbuilt by the system. The system lists include cursorwheels and dimwheels.


Suppose you want to do something in ZigZag. You have many design options, giving you considerable breadth.

To solve any problem, you can choose among

            - new dimension(s)

            - new cell types(s)

            - new operation(s)

            - new view(s)

            - new convention(s)

            - new compound cell types

            - preexisting constructions and configurations

            - new constructions, configurations

In general we have found surprisingly simple solutions to various problems using only one or two of these.


ZigZag will be delivered as a package, presumably bundled with a larger Xanadu-based text system (called either CosmicBook or FloatingWorld).

This package will include, after installation--

    - a directory

    - various code libraries (esp. SDL)

    - the executable

    - Slice 00 and Slice 0

As users put data into the system, additional slices will be created.

When fired up, the system unifies different slices into a unified conglomerate of conected cells, always including Slice 00 and Slice 0. At the minimum slices are unified along their Home cells, allowing stepping easily.

Operations take place within this conglomerate.


*(In earlier specifications, link-locks were part of the design; you could create unbreakable links. This has never been implemented. These would probably not be implemented in cellular structure.)


Cursors have their own wheel. This simplifies stepping among cursors. "Next window" steps a pointer to the next cursor on the wheel.

"Next window" brings a different window to the foreground, by stepping the current-cursor pointer to the next cursor on the cursorwheel. This is done by cellular structure, i.e. zigzagular mechanisms. allowing the user to step through the dimensions and views.


Each cursor needs certain data, which are of course kept in cells. A cursor's set of data is called a cursorplex, which is connected to the cursor cell along the cursor wheel. A cursorplex consists of a cursor, a set of axes with their current assignment to dimensions, a current view, and possibly other units needed by specific cursors.

*(While we have so far used them only for windows into the system, cursorplexes may be constructed for many temporary tasks, vaporizing afterwards. We may in the future use the cursorplex instead of register, window, movable pointer, and processes set in motion, such as subroutines and coroutines. This is discussed further below.)


The axes of a cursorplex are called x, y, z; and if more are required, we successively add w, v, u, t... (Suggest skipping u because it can be mistaken for v.)


There are many possible operations. Only a few have been implemented-- those required for the cursor and views, and a set of user operations called Kblang.


The cursors step invisibly along the data structure, connecting to the accursed cell along d.cursor. Since two cursors (more in principle) may be on the same cell, they ignore each other.

(It was a good choice to make cursors obey the same connection physics as other cells, since this helped debug and unify Andrew's earliest system.)


KBLANG(tm) (Keyboard Language) is our standard set of keyboard bindings to the most basic ZigZag operations-- new cell, delete cell, connect, break, step, clone, hop. Note that all of these (except delete) take a direction: left, right, forward, back. (Note that d and k are intended as forward, D and K as back-- there was ambiguity about this.)

*(KBLANG MACROS TO EXTEND ZIGZAG: it has been long intended that you can record a series of Kblang characters and replay them with different cursors, affording a simple and powerful extension of the system.)

*(Operations not yet implemented--

    - three or more windows

    - cursor-following (one cursor automatically follows where the other goes)

    - shear (moving of two ranks relative to each other). Has edge-case issues.

    - chug (moving of a rank between other ranks; two-sided shear). Has edge-case issues.

And more.)

*(Generation of cursors for multiple new windows, for temporary purposes and to follow scripts.

    - cursor-fork

    - cursor-kill, the complement of cursor-fork

    - next-window (brings the next window to foreground)

These are intended to fire up and manage new windows and coroutines. It is also intended that you can turn off the view, allowing a cursor to run a process in background, without view or refreshment.)


Undo and Redo have been implemented in Gzz and Zzz. I hope we can imlement them in ZigZag with a Hypertime model.

*(In Gzz there are a number of interesting further commands, some of which I may accept as defined by Lukka. These include: switch cursors, switch cells under cursors, next cell on clonerank, go to headcell of clonerank, put out concatenated text, and more.)

*(The cursor's motion has been generalized into an operation called step negend (only implemented in Zzz). What this does:

    - selected cell steps in specified direction

    - at end of op, selected cell is next-to-last cell in rank (just above the negend)

This is useful for sorting out such operations as stepping on dimwheels.)

*(The full specification of marking has never been implemented. In the full specification, a cell is marked by a marking-cell connected in d.mark.

    - The chain of these marking-cells can be easily followed even though the marked cells are scattered.

    - Different mark-chains may be created for different purposes.


*(Operations on marked sets have never been implemented. The marking operation was always intended to make cells act as a unit for deletion, cloning, hopping etc., but it has only been implemented as passive coloration, just turning cells red.)

*(Backplane functions have never been implemented. These create a kind of equivalent of object-oriented structure.

    - The user defines a template or backplane with specific entities and functions represented by cells. The corresponding related cells in different planes and documents will be found by the use of this backplane.


    - Example: A backplane may have the designations "movie title," "producer," "director," "leading man," "leading lady.") These roles may be specified on a number of different documents. If you select a movie title in such a document, bouncing to the backplane will allow you to specify "director" and "leading lady" as related entities in the template, then bounce forward again to the corresponding role in the same document. Meanwhile, the same backplane can be designating the same set of roles in many other documents and listings.

    - Restriction: a given plane can have only one such set of such entities.

    - Power: a given plane can have several entities with the same role (multiple-cell intersections)



A view, or skin, is a system of search and presentation of zzcell connections. A view should be always up to date, being refreshed after every change in the data.

There are no right or wrong views, and new ones will be always welcome. (Note the profusion of views in Lukka's Gzz system.) There is no limit on views except comprehensibility, and that is an issue of taste and consciene.

A view typically begins at one cell and shows the cells encountered in a specific walk or trajectory away from that cell. These cells, and their connections, are assigned to 2D or 3D presentation. How many cells out to carry the view (depth of search and refreshment) depends on various factors.

A view can be done in many other ways, e.g. to find connections as a walk between two selected cells, finding the shortest connection between them, or other kinds of trail. Lukka's "matrix" view in Gzz appears to start with two ranks and find the intersecting cells.


A serious issue in design of views is unifreshment: avoiding showing a cell more than once. In the simpler refreshment methods employed by Azz, Ezz and Zzz, each rank is refreshed independently (straight or plain refresh). This can lead to a cell being shown more than once.

Unifreshment may be done in a pre-scan or during the actual display algorithm.

Only Lukka's Gzz version has implemented unifreshment. Apparently his method lists the cells as they are shown; the second appearance of the cell is shown connected by a spline. (This list or stack can be overwhelmed in the MindSunDew view, resulting in numerous simultaneous appearances of the same cell.)


In unifreshment, cells may appear in loops.

Note that in 3-space a loop needs one more parameter than a straight rod, in order to specify the loop's second angle in space.

Another trick in unifresment is the spline, a wiggly line connecting cells.


A dimension may be thought of as a flag on a link that determines how it may be shown or operated upon. A dimension may also be thought of as the collection of all the ranks that participate, i.e., that have connections along it.


*((It's not clear how dimensions should be named. With so many characters available, we should branch out from "d." (A dimension name is a string, after all.) I will be deciding before first product. The ".." convention for dependent dimension is still under consideration.

Dimension names should be allowed to have nicknames and synonyms. However, they should be recognizable as such to avoid conflict.



Utility dimensions:

    - d.1 (suggest use like horizontal line on paper)

    - d.2 (suggest use like vertical column on paper)

    - d.3 (free to use as you like)

    - d.4 (free to use as you like)


*((Not listed here.))


*((When ZigZag is released as a project, I want it to have a system of preset dimensions, skins and routines for personal databasing. These will include--

    - d.marriage

    - d.children

    - d.time


    - d.address



and others.))

*Other dimensions of interest, which have been only partly implemented and are not currently planned in--)

    - *(Active dimensions, e.g d.autocalc, d.xeq (implemented by Benja Fallensein), d.concat)

    - *(d.cellversion intended to track previous versions of cells)

    - *(d.sliceversion intended to connect successive versions of slices)

    - *(d.contain and d..contained-set together represent containment (generalizing directories in the operating system). What can be done on contained content has to be specifically programmed; we have experimented with--

        -- programs contained, thus made to work as a whole

        -- playing of CD tracks

        -- certainly works for Inventory.

*((ZigZag-based languages have been partly implemented, e.g Benja's "Flowing Klang", which required Java expression of its routines, and TN's NUZZL, a sketch for a Prograph-like dataflow language in ZigZag.))


The axes of a view are called x, y, z; and if more are required, we successively add w, v, u, t... (Suggest skipping u because it can be mistaken for v.)


A dimwheel is a wheel which lists dimensions. It is made up of cells we call dimdesignators. In the ZigZag design, a master dimwheel holds all the dimedesignators, and additional dimwheels may be created for convenience which clone the dimdesignators.

Reference to a particular dimension is made along a connection to a dimdesignator. For instance, the assignment of dimensions to a current view is done by connecting the axes of the view to the particular dimdesignators.

*((These references will be positive or negative references by some mechanism yet unchosen, possibly hopflags, or connection to the positive/negative side of the dimdesignator.))


A cell has

    - an ID (see below)

    - contents (except for cells used as spacers)

    - connections

    - type (see below)

    - mode (clone, remote clone, node/account/owner)

    - time of creation

    - owner/creator (specified by node/account/owner)


*((We have never implemented "time of creation" on a cell, though this would be good. This mechanism need not be zigzagular.))


Each cell has a cellID, which never changes. If the content changes, the cellID must change for most data types. The cellId consists of

    - its cellnumber in a given slice

    - its slicename (without slice version)

    - its node/account/owner

Links are to these full cellIDs.

(CellIDs were implemented as far as cellnumber and slice in the Zzz system.)


By 'type' we mean that a cell is flagged for recognition by certain programs or routines.

Cell types implemented so far.

    - text cell

    - executable cell (i.e., connected to code). These have existed (differently) in Azz, Ezz, Gzz.

    - clone. (Not actually a type but a mode additional to whatever type of cell is being cloned-- a clone's type is the same as that of its headcell.) A clone gets its value from the headcell along d.clone. D.clone is constrained: it may not be broken. If the headcell is deleted, its value is automatically passed to the next cell.

    - TREFL (Text Reference Locator)-- a rank or compound cell forming a pointer-set pointing out to text, virtually equivalent to that text. Implemented in Zzz.

    - Argle, voland (cell types for the programming language NUZZL, implemented in Zzz).

*(Specific cell types not yet implemented. Listed roughly in order of need--

    - remote clones (see below) (Not actually a type but a mode additional to whatever type of cell is being cloned-- a remote clone's type is the same as its headcell.)

    - preflets (see below) and their resolution

    - unchangeable cell types (if they change, they must get a new cellID)

        -- Text (in versions so far, they have been changeable)

        -- Graphic (as texture maps)

        -- Audio

        -- Video (as changing texture map)

    - viewable piping or snipping for multimedia

    - dynamic (allowed to change without a new cellID-- e.g. the sum of other cells)

    - compound cell (it's legitimate to represent any collection of cells in a compound cell-- connected back in d.compound)

    - other exotic types variously designed-- e.g argle, voland of NUZZL

and a variety of others that have been thought of.))


Slices are specific structures for packaging contents, thereby combining and extending the user's data world. Slices explicitly divide the universe of cells into specific user-chosen sets or vessels. Slices may be used to combine and extend the user's data indefinitely. (Automatic virtual-memory cell management does not seem plausible at present.)

Slices are presently implemented as files, but that is not a logical requirement.

Terminologically, we say that a slice is "resident" (in RAM) or "absent" (Outside, Apart).


Waffle is our old term for slices commingled with data content. Clusters and clumps are our old terms for bundles of cells sent from outside that we wish to merge with our own.


Cells may be brought in from outside as slices or as waffles. There is some question as to whether we need different formats for cells sent by other users (clusters or clumps).

When a slice becomes assimilated to another slice, we call it "merging."

We also have a process for virtually merging two or more slices when they are co-resident, but re-separating them when one is dismissed from RAM. For this we use the term "intercalation". Intercalation is to be managed by the system of constraints we call preflets (below).

*((How the user will select and manage what to merge is a problem we are just now considering.))


Slices have been implemented in many forms, though few of these have been thoroughly tested--

    - hash tables (Sleepycat free license)

    - XML (Lukka's format)

    - hash tables (Jeremy Smith's own bespoke code)

    - (others I presently forget)

    In the present situation, we should probably go with the simplest format, which I leave to others to decide. *((While I don't want to be mouse-milking, it does seem to me that the huge number of instances of "KEY" and "VALUE" could be cut back-- not so much for space as readability. No rush about that.))

=SLICE NUMBERING. While a slice may have a name, it also has a number, which is used for certain priorities.


*(A backup of a given slice presumably has the same number, possibly suffixed with a version number.)

*(The plan has been to connect versions of the same slice along d.sliceversion.)


        (Cf. 00 and 0 on downmarket roulette wheels-- 00 comes first in the collating sequence; if negative integers are included, it stands outside the collating sequence, neither odd nor even.)

Slice 00 and Slice 0 are intended to be always resident and may at any time be freely intercalated (see Preflets).

Slice 00 may be intercalated from other slices but not otherwise changed by user acts.

Slice 00 is intended to be replaceable by Us without creating problems for the user. It is intended to contain system content, system structures and programs at the cellular level (not binary code, which is assumed to be in the main program). It is supposed to be independent of user content and settings; i.e specific cells in Slice 00 that the user is expected to connect to will not get new IDs in success versions. This is so We (the software providers) can in principle replace Slice 00 at any time without disturbing the user's data arrangements. The user's chosen settings and geography will stay unmolested in slice 0.

Slice 00 is intended to contain information the user may not change--

    - Home cell (non-deletable)

    - the main dimwheel of pre-supplied dimdesignators (to be intercalated with the user's dimdesignators from Slice 0)

    - possibly some sub-dimwheels pre-supplied

    - operation addresses in the main program

    - executable opcells pointing to addresses in the main program

    - executable scripts in cross-platform interpretive code, if any

Specific cell IDs in Slice 00 may be hard-coded for addressing by system code; i.e., we promise they will not change.

Slice 0 is intended to contain user-changeable information that the user wants always resident.

    - the user-changeable geography of the system

        - Main Street (horizontal) and Park Avenue (vertical) intersecting at Home Cell (by intercalation)

        - user-arranged docking points

    - user-maintained dimwheels and secondary dimwheels, cloned from main dimwheel or from this slice

    - *((user settings, none currently defined-- presumably as specific cells addressed by the system.))

Specific cell addresses in Slice 0 may be hard-coded for addressing by system code, but the user is free to get rid of them.



(Assumed: slices are in the same directory.)

At startup, the system makes a list of the slices in the current directory (possibly other directories) and attaches it to a docking-point in Slice 0. The user selects any slices to be brought in (preferably by hopping their names across a column as hopflags) and the system brings them in. *(If there is not enough room, the system should say so.)

*(d.sliceversion, never implemented, is intended to connect identical cells in successive versions of a slice.)


*(Slices are connected in various ways when they become resident.

    - all currently-resident cells are connected by home cells (cell 0 of the slice). User may step between slices along homecells.

    - all cells with the same cellID are automatically connected along d.cell-identity. (This generalizes the previous point.)

    - remote clones are resolved (see below)

    - preflets are resolved (see below))

At dismissal, these steps are undone (see below for the methods).


Some people find remote clones mystifying. They are very simple. A remote clone is simply a clone. However, it is a clone of a cell not present in the current slice. (Therefore the content must be carried along in the slice, but may not change.)

While remote clones may actually ride inside a given slice, when the chance comes (co-residence with other slices) they become connected on the clone dimension to equivalent cells in other slices.

RESOLUTION PHASE WHEN SLICE COMES IN: Remote clones are checked against already-resident cells. If the master cells are detected, or other remote clones of the same cells, the new arrivals are put on the clone dimension.

DE-RESOLUTION PHASE WHEN SLICE GOES OUT: Remote clones leaving RAM are disconnected on the clone dimension.


Some people find preflets mystifying. They are very simple. Preflets are simply a mechanism for automatically interweaving cells from different slices when the slices come together. Thus their only implementation is in the connective process that occurs when a slice is brought in (or dismissed).

I believe we can find many powerful uses for the preflet system. The example in my patent application, of a movie script connected to a schedule and director's comments, shows how different combinations can work (the script and the schedule; the script and the comments). This is only the beginning.

Important benefits of the preflet system:

    - allows connections in detail among merged conglomerates of cells

    - allows stitching content together in any direction indefinitely

    - allows adding detail in successive levels indefinitely

    - allows different contexts

    - there are no half-links or broken links in the system

    - every slice is integral when it is alone, properly connected within itself

    - the intercalated conglomerate is integral, properly connected within itself

    - there is an exact process for merging slices


Preflets are automatically made when the user connects cells that happen to be in different slices.

A preflet expresses a desire. Any cell may express a desire to be near another given cell (target cell); as slices are combined and decombined in RAM, the preflets are honored according to rules. The preferring cells are connected to the target cells according to a simple algorithm.

A given cell may express only one preference on a given dimension, and only negward. This keeps it relatively simple. *(I previously allowed two degrees of desire, Insistence and Want, but we'll skip that for now.)


A cell expressing a preference for a cell on another slice is given a connection on +d.preflet to a preflet cell (which is simply a marker indicating that a preference exists). This in turn has a connection along the dimension of desire to a cell which represents the intended cell.

    - Example: Cell A in slice 33 wants to connect on -d.2 to cell 175 (on whatever slice). Therefore cell A is given on +d.preflet a preflet cell which connects -d.2 to a cell containing the cellID 175.


Cells with preflets are checked against the cells they want to be next to, and reconnected near their target cells according to a simple algorithm:

    - How many cells want to be connected here?

        -- If no others, the connection is granted

        -- if there are others also expressing that preference, all but the least-priority are broken out of their positions and attached. They are honored in turn, those with lower slice numbers having higher priority.

        -- For each, a "return preflet" is created which show the cell the way home-- how to reconnect when the slices are no longer connected. This is done by hopping its preflet cell to -d.preflet and registering the positions on it which show where it came from-- its current position prior to merging.

    - Does the target cell have an empty connection in the preferred dimension?

        -- if not, connections are broken to get all preferring cells attached

    - Is there an open connection plusward from the last cell on the desired rank? (I.e., is it on the end?)

        -- If so, no further connections need be broken and the cells further plusward of the last preferring cell are automatically joined as well.


        This last option permits the virtual connection of ranks, not just cells.



The cell has never actually left its home slice; its representation remained in the original slice while it was connected to cells in other slices. However, the point is to return the slice to integral form when it goes out.

The slice to be dismissed is restored to its original structure, using the return preflet to reconnect to its original location in the slice. The preflets, now +d.preflet from their choosing cells reflect the cell's final position in the conglomerate from which it is being removed. (But with reference to the original destination slice.)


*((Groups of cells, possibly with media content, may want a different transport format besides slices-- for instance, when exchanged dynamically among users in some chat-like protocol. This may work well with Mantra, below.))


James Goulding has done a deep design job on a server for zzstructure and ZigZag, called Mantra. Its protocol is desiged for efficient wrapping of replies. It has simple structural representation of zzstructure but not of ZigZag.

Mantra appears to be excellently suited for server-based applications in ZigZag business.


While email is a specific application, I mention it here because of its importance.

The plan is:

    - use a standard POP server and standard .mbox file

    - instead of the standard database software that shows columns of mail (subject, sender...) we do the equivalent database in ZigZag. This will permit special new functions of presentation and search. (We will also add transclusion, at the FloatingWorld level.)


In this era of viruses and spyware, we want to be clean. Here are some security holes:

    - scripts can of course do anything on the computer, and so users should be warned. We probably do not want to distribute scripts ourselves.

    - incoming slices should not be executable, only showable.

This is only the beginning. I am sure there are many more points to be made here.


connection physics

    rules of zzstrructure; the principled system of discrete interconnections and operations of zzstructure; the same as extended by ZigZag.


    making sure a cell in a view is shown only once.

straight or plain refresh

    refreshment of a view that simply shows each cell as encountered. This can lead to a cell appearing more than once.


    mode of a link that makes it unbreakable.

slice conditions

    presence, absence, summoning, arrival, dismissal, departure, residence, co-residence.


    (This is a dictionary word.) Place discrete elements between. (Much used in chemistry.)


    slice containing media content or non-zigzagular data.


    little waffle, possibly for sending through email or other channels.


    mini-constraint which tells cells how to intercalate.

return preflet

    mini-constraint which tells cells how to disintercalate.

connection physics

    rules and principles of zzstructure.


    following the rules and principles of ZigZag.





There are no documents that refer to this sourcedoc.