xuzzCrystals-D5
=== 13.05.30
CRYSTAL DEFINITIONS OF XANADU, ZIGZAG AND ZZOGL ENGINES
Theodor Holm Nelson
Founding Designer, Project Xanadu
Note: Xanadu® and ZigZag® are registered trademarks of Project Xanadu. TransLit™ is a claimed trademark of Project Xanadu.
Please make replies to this short and narrow; they are much easier to handle.
(Formats for these systems are DEFINED ELSEWHERE.)
This is long-term. It is meant to be an ongoing overview document— incomplete, changeable over months and years-- for the external definitions of Xanadu, ZigZag, Zzogl, etc.
(By “external definition” I mean to state how the system should respond and what it should respond to, leaving
alone the possible internals.)
I am not sure what to call this kind of specification document. I am not sure if there is a standard term for it.
By “crystal” I mean to describe it more or less the way a crystal is described, from outside—
- hard-edged
- index of refraction, how it responds to the light
- angles of fracture
or whatever. Anyway, it sounds nice.
NECESSITY OF CLEAR DEFINITIONS
It is absolutely necessary to have clear and unforkable definitions, as do Gnu, Fortran, Common Lisp, etc.
Forking pretty much killed Lisp (Common Lisp came too late), and did a lot of harm to Unix.
Gratuitous variations and unexpected creativity by programmers have repeatedly delayed and damaged these our projects. So I want to nail down as much as possible as soon as possible.
OBJECTIVES
I want to enumerate—
- the functions that are definitely part of these systems
- functions that should be available, with answers to various queries that I would want
- ways that persons with limited programming ability (not naming names) can get specific information out of a system
- ways for other people than the main developers to tweak interfaces
KINDS OF THINGS TO DEFINE
- main operations
- inputs and outputs
- hooks for new operations
- xanadu generic views
- hooks for new views
THIS IS ALL VERY TENTATIVE
In describing functions that are desirable, I am quite open to better definitions with the same general intent.
=== === === XANADU AND TRANSLIT
Note that “TransLit” now refers to xanadocs, xanalinks and EDLs in general. Anybody can show them any way they like.
“Xanadu” refers to software, especially client software, for these formats, under my direction and philosophy and style.
=== EDIT OPERATIONS AND THEIR EFFECT ON THE EDL
- start xanadoc
- name / rename xanadoc (actually a link and insertion or transcusion)
- insert [add to some stabilized document, e.g. permascroll, and to the EDL]
- transclude (between pages or xanadocs)
- delete [remove from the EDL]
- rearrange (within a xanadoc)
- copy [in the sense of transclude] in same document
- make link: select endsets and type (my preferred order of doing this is not in the definition)
- change link, creating new version of same link [discussed somewhere but not in last couple of years, I think]
- publish doc
- publish version
=== MICROVERSIONING (add-on to Xanadu editing)
- new op (IMPLICIT; saves op type, concatext pointer(s), content pointer(s)
- fork new version in oplist (returns EDL)
- backtrack in oplist (returns EDL)
- forward step in oplist (returns EDL)
- open separate microversion in parallel
=== OPENING AND CLOSING OPERATIONS
May vary with Xanadu version.
= PARTIAL-PRESENCE MANAGEMENT
The conventional notions of a document being “open” and “closed” apply to conventional documents which are encased in a file.
The corresponding states for a Xanadu client should refer to a document being “currently partially present”.
=== === === THE ZIGZAG VIM AND ITS LEVELS
ZigZag is a Virtual Interactive Machine (VIM).
=== KERNEL ZIGZAG (embeddable)
This should be WITHOUT VIEWS, but hooks for views
=== STANDARD ZIGZAG, ZIGZAG1
Standard KBLANG operations—what do they return?
- presumably a cellID for the accursed cell
- presumably a set of currently-viewed dimensions
zzView spec, to hook in
- generalized (including eg 3D)
- gzz method
- FIX LUKKA’S change of ‘insert’, which breaks connection automatically
=== ZIGZAG2, KBLANG2 (new name for some of the old specs not yet implemented—but by no means all)
ZigZag2 refers to the engine. KBLANG2 refers to the operations it performs.
ZigZag2 has
- N cursorplexes (starting with one on d.1,d.2,d.3)
- program-by-example record, end recording, and play
- NO VIEWS, but hooks for views
- SEARCHABLE, making it a more like a
regular database
- give name to cell
- link-locks
- permascroll for input text of ZigZag, allowing its use by Xanadu
= NEW OPS (KBLANG2)
- stepout (escape from a list, takes two directions)
- giraffestep (takes two numbers and two directions)
- reduce function to standard KBLANG (for new users)
- chug (to be discussed)
- shear (to be discussed
= SLICE OPS
- create slice
- dismiss slice (out of RAM, out to storage wherever)
- bring in slice (to RAM from storage wherever)
- kill slice
=== ZZOGL, THE GENERAL SCENE INTERPRETER
A Zzogl scene is a zzstruture of OpenGL objects and parameters that can be shown as a 3D scene using the Zzogl interpreter. It is dynamic—created as a scene using ZigZag cells, not compiled.
The user, by specifying an operation, implicitly creates a new Zzogl scene, then sworfs to it.
- Inputs and outputs
- viewable through OpenGL
- constructable through ZigZag
- operations for various moves
- operations for various presentations
In existing implementations (i.e., XanaduSpace and Xanaspace), a Zzogl scene is new-created, used, and then discarded.
In future times, there may be ways to—
- enact or sworf part of a new Zzogl scene, as a subset of a larger scene
- preserve Zzogl scenes and partial Zzogl scenes for re-use and assembly.
These are just thoughts for the future, however.
= CONSTRUCTION OF ZZOGL SCENES THROUGH ZIGZAG
We may create ZigZag routines for building new ZZogl scenes. These may well be doable in program-by-example mode.
We need to know--
- How to plug in a scene newly-built by ZigZag, so it will sworf correctly.
=== ZZOGL XUPAGE FUNCTIONS
We need--
- function that returns a list of current page objects
- to plug in a new Layout
- to specify where new pages go on screen
- to specify sworfing behavior
- to specify how to select pages
= XANAGRAMS (document overviews)
How to plug in a new Xanagram
- sworfing pages in and out of the xanagram
How to plug in new page views
- making sure their contents sworf correctly between different page views
- irregular page views, as shapes
- loop page view (implemented early by Rob Smith)
- conveyor-belt page view (planned with Rob Smith
How to plug in new beam views
- e.g. textures on a beam, or moving textures
- e.g. twinkles on a beam
=== ZZOGL BEAM FUNCTIONS
- function that returns list of link beams on a page, as list of beam objects
- function that returns list of source transclusion beams, as list of beam objects
- function that returns list of local transclusion beams, as list of beam objects
- function that returns edge-points on current slab of a particular beam
- function that returns concatext positions of a consecutive displayed endset portion
=30=
span: