zz: Units and structures, more (was Re: [zzdev] A big suggestion

[Ted Nelson <ted@xxxxxxxxxx>]

Hi guys--

In my earlier remarks, I belittled the notion of 'units' too much.

Actually the ZigZag design is intended to facilitate *lots* of units--
? A *row of cells* may be very like a database 'record'.
? A *table* is a unitary structure where elements may be looked up
 simultaneously by row and column (and additional dims if desired).
? In the Holm family genealogy demo, a family (parents and children)
 is represented by a T-shaped structure (parents the crossbar,
 plus-sign to indicate a marriage with offspring, names of children
 in birth order.

We can think of these as 'recognized' structures, which may be
 replicated, viewed in specific ways, and programmed against.
 Lots of other replicated units, with other shapes, can be defined.

Big ZigZag differences are--
? the boundaries are unconventional and permeable. 
? "Closure" is not required: structures may continue in any direction.
? Elements may be simultaneously in more than one recognized
 structure.

And probably more.

All best, Ted

======================================
>Date: Thu, 27 Jul 2000 13:04:35 -0700
>To: zzdev@xxxxxxxxxx
>From: Ted Nelson <ted@xxxxxxxxxx>
>Subject: Re: [zzdev] A big suggestion
>Cc: ted@xxxxxxxxxx
>
>Hi Benjamin--
>
>I haven't had time to look at your suggestion in detail,
> but I think there may be a miscommunication.
>
>You offer
>>A recommendation to applitude programmers to split up their applitude's
>>data into "things," as small as possible, which adhere to ...
>
>The whole point of ZigZag is that separate aspects of
> the world are *not* separated into different things.
>
>An applitude is a zone of functionality which is *not*
> split off.
>
>A key problem with the conventional computer world
> (like OpenDoc etc.) is this segregation.
>
>>I've also included a detailed specification of a possible
>>set of interfaces inside this system. 
>
>That's what the whole design is about-- especially
> figuring out which dimensions and constructs work best.
>
>Anyway, I look forward to studying your piece.
>
>Best, Ted
>
>
>At 11:54 AM 7/27/00 +0200, you wrote:
>>Hi everyone,
>>
>>sorry for the delay -- it was harder to find a telephone line than I had
>>expected. Now, I still can't exactly ask questions because I have to get
>>familiar with the new code that has shown up in the meantime first.
>>Pondering about my programming system applitude, the formatted text
>>applitude and other applitudes, though, something else has formed in my
>>mind which, I think, deserves consideration on your part: a suggestion
>>for a system with the function of systems like OLE or OpenDoc, linking
>>different applitudes together. Besides the general description of the
>>suggestion, I've also included a detailed specification of a possible
>>set of interfaces inside this system. Probably I haven't thought of
>>everything, as this is a very first draft; but if the system itself
>>makes sense to you, tell me your problems with the spec, and I will try
>>to make a better one.
>>
>>Hope this is of help,
>>- Benja 
>>
>>
>>
>>ABSTRACT
>>
>>A recommendation to applitude programmers to split up their applitude's
>>data into "things," as small as possible, which adhere to a common
>>interface (not unlike OLE, but better), so that they can be reused in
>>other applitudes.
>>
>>
>>
>>DESCRIPTION
>>
>>In the draft for Cybertext, you (Tuomas & Vesa?) say: "The interesting
>>thing about applitudes is that they can be designed to be connected to
>>each other in a more fine-grained fashion than current embedding
>>frameworks such as Bonobo, KParts, or OLE/COM." I think such connections
>>can happen on two levels: custom applitude connections, which are
>>designed to connect a special applitude A to a special applitude B; and
>>connections within a broader framework, where all applitudes have a
>>common interface through witch they can communicate with each other. Of
>>course you can always connect a cell which has a special meaning to
>>applitude A to a cell which has a special meaning to applitude B on a
>>dimension of your own, but these connections will show in neither
>>applitude's views; this is exactly what we need, though. For example, we
>>want to include a picture in a text; ZigZag should empower us to use ANY
>>kind of picture supported by ANY gZZ applitude, not only those the text
>>applitude was designed to support. This, after all, is what we mean by
>>breaking up monolithic applications, isn't it?
>>
>>So, what we need for gZZ is something with the same function as KParts
>>or OLE/COM; not with the code overhead, as we're going to use the ZZ
>>model (that's gZZ's main advantage here), but with the function of
>>inserting one applitude's stuff into another applitude's stuff. We want
>>it to be more flexible than those examples, though, and we can have that.
>>
>>My suggestion is to represent data structured into things -- that's a
>>bunch of cells refered to by a handle. This is an extension of the
>>"everything is a cell" concept, not something to complement it; the idea
>>is that the handle cell is the "outside" of the thing, whose "inside" is
>>the bunch of cells. The problem is that not everything can be a cell in
>>the current gZZ system; a bunch of cells can never be one cell, and each
>>nontrivial data structure needs a bunch of cells, not only one. A very
>>basic operation a handle should support, for example, is that marking
>>the handle marks all cells of the thing as well (or optionally does);
>>this way, a user can send the whole item by eMail easily. However, how
>>this exactly works is outside the scope of this suggestion draft.
>>
>>By Ted's definition (cited from memory), a thing is an item that can be
>>used (accessed) by a ZZ programmer; and an item is anything that is of
>>interest for a ZZ user. Mine is just an operational definition, but I
>>MEAN the same.
>>
>>I suggest that a text vstream, for example, be a thing. It can contain
>>other things, like pictures (this is an extension of the vstream
>>concept, but I think a good one). On the other hand, it can be contained
>>in other things, like a spreadsheet. It can be contained in *multiple*
>>other things, by cloning the handle. As the handle is the "outside" of
>>the thing, cloning it creates a second "outside," with the SAME
>>"inside." This is not exactly Euclidean, but that shouldn't be a
>>problem. :)
>>
>>Things inside things don't need to be a different "kind" of thing than
>>the thing they're in. (Possible name for things inside things:
>>subthings.) A text vstream can contain another text vstream, and this is
>>my suggestion for your "structured text," Tuomas. You can make different
>>chapters (text vstream things) and put them into a book (another text
>>vstream thing). However, you can also clone them (their handles) into
>>your TODO list, or you can put them into weird constructs (yeah, you can
>>clone a chapter into itself, although it doesn't make much sense to ME).
>>You can as well use them as subthings of totally different things, and
>>this might be more exciting. Using them in an item cloud (more general
>>form of a text cloud) comes to mind.
>>
>>Now, a thing knows different ways to "visualize" itself. (How exactly
>>this works is part of the specification, below.) This concept is broader
>>than it sounds: I consider a sound output "kind" of a visualization, for
>>example. That way, you can have a sound vstream inside another sound
>>vstream the same way as with text vstreams, and they will play right.
>>But the same sound vstream items can have a visualization on the screen;
>>this is a real visualization, then. Maybe the more general concept
>>should be called "accesibilisation," but this sounds to complex and
>>artificial for me.
>>
>>A visualisation (my abbrevation: viz), thus, is a way to bring a thing,
>>as a whole, to the user. Screen visualizations will commonly be rasters
>>(although you could say that special-case gZZ flobs are part of the
>visualization).
>>
>>An applitude will now define a number of "thing types." A text vstream
>>applitude will only define the text vstream thing type, but more complex
>>applitudes might define more complex thing types. All things of the same
>>thing type are connected to a list of possible visualizations for this
>>thing type. There's no formal definition; but it's implicit that a thing
>>connected to a visualization have to be readable by the visualization.
>>All the parameters the visualization needs have to be there, etc.
>>
>>A visualization is only referenced from the structure; the actual
>>visualization is the Java class which does the layouting on the screen,
>>prepares the sound output, etc. These visualizations are grouped into
>>viz typees, which, unlike thing types, have to be well-defined in the
>>Java manner of an Interface (or an abstract class). Now, when the viz
>>code of a thing finds a subthing (e.g. a chapter vstream in a book
>>vstream), it calls gZZ to get a certain visualization of this subthing.
>>A text vstream requests a text layout viz, for example; this viz is
>>defined to be able to layout a text line-by-line (so that it can be
>>billowed). If there's no such viz available, it requests a viz layouting
>>the whole subthing into a rectangular area. This works with pictures; it
>>also works with virtually everything else, like sound things which are
>>visually represented, etc.
>>
>>The box viz is also used to layout a thing into a cell raster. That's
>>true, a thing's outside (it's handle) isn't shown as a label, but as a
>>visualization of the thing. This seems most useful, as often you don't
>>want to assign a label (I don't think of my series of dog pics as dog
>>pic 1, dog pic 2, dog pic 3 -- that's a ideosyncracy invented by the
>>file system). If you want labels or icons anyway, no problem. There will
>>be a label applitude which defines a label thing type, visualized as a
>>label, but containing as a subthing the thing which is meant by the
>>label; pressing the right key will jump right into editing the subthing,
>>just like it would if you'd use the thing directly. Same goes for icons.
>>
>>Each thing (more accurately: each thing type) has a list of possible
>>visualizations, ordered by preference. Also, there is a list of standard
>>"viz converters:" the most important example being the converter from a
>>text viz to a box viz. Such a converter is never invoked by the user;
>>the system uses them internally. The converter implements the interface
>>of the viz type they convert to, but the implementation internally calls
>>the viz converted from. The converter mentioned above is invoked all the
>>time, over and over, to convert from the standard text viz of non-handle
>>cells (representing the cell's contents) to the box viz used by the cell
>>rasters. (Although possibly this is to slow and there'll be an
>>efficiency hack which goes around visualization search in this special
>>case.) When an item doesn't define the viz type requested, gZZ searches
>>its converter list for a conversion to the desired viz type, and if it
>>finds it, it returns an instance of the converter, which "masks" the
>>"real" viz.
>>
>>An interesting special-case viz is the HTML viz. This doesn't put
>>anything on the screen, but generates an HTML document representing the
>>thing. This can be used in conjunction with Ted's idea of http://
>>requests returning a HTML page, while xu:// requests return the cells
>>(or other Xanadu data). The HTML viz would be invoked to create the
>>http:// results.
>>
>>Another interesting viz, which would be helpful for my applitude, would
>>be an "execution viz," which doesn't visualize something on the screen,
>>but instead executes the thing. If the interface for this is general
>>enough, it allows combination of different gZZ programming languages.
>>
>>If no viz of the requested type and no conversion can be found, the
>>layouter requesting the viz must define what to do; it might inform the
>>user that there was an error, or it might just ignore the subthing.
>>Maybe it could render the handle cell's contents instead, if any.
>>
>>Some UI considerations: A text thing might want to blend in other things
>>containing text seamlessly; that means that the insertion cursor, when
>>it it moved over the edge to another thing, is just passed on to that
>>thing. This is represented by moving the zz cursor so that it points
>>into the subthing. With pictures, on the other hand, it might be
>>desirable not to pass on the cursor, but to put the cursor onto the
>>whole thing; this is done by moving the zz cursor to the handle of the
>>subthing. Which of these behaviors is used is in the hands of the thing
>>which has the insertion cursor before it is moved.
>>
>>Things are useful for drag&drop between applitudes. When you start to
>>drag, the gZZ flob reacting to the mouse event is called for a cell
>>which is dragged. This can be just a cell, or it can be a handle to a
>>thing. You can drop a thing virtually everywhere. The two places where
>>you can store things you don't need at the moment are clouds and the
>>cell rasters themselves. Clouds are useful when you don't need a special
>>structure, just want to store a group of things. If you want to order
>>things in arbitrary structures, you drag them on a cell raster. Here,
>>every cell has four sections (left, up, right, and down); they are
>>divided by two diagonal lines, from the upper left corner of the cell to
>>the lower right, and from the upper right to the lower left. If you drop
>>a thing on one of the sections, it is inserted in the associated
>>direction from the cell: dragging it in the down section inserts the
>>thing on Y+ from the cell (or rather, inserts the thing's handle). When
>>you shift-drag a thing, its handle is cloned. (The clone of a handle is
>>considered a handle of the same thing.) Note that you can drag&drop
>>non-handle cells the same way, including cloning.
>>
>>Something that deserves some consideration are the editing modes. I
>>would like both in-place editing and own window editing, but in-place
>>editing should be the standard and own window editing should have to be
>>requested by the user. This, by the way, would be helpful for normal
>>cells as well, when you use a raster in which the text you need doesn't
>>fit: you'd press one key and a new window pops up in which you can enter
>>a word-wrapped text as long as you desire.
>>
>>In-place editing poses a tricky problem, though: which things can
>>currently be edited and which can't? If I have a tree of text vstream
>>things, then I want to be able to edit the different parts of my text
>>seamlessly: moving from one text to another with the insertion cursor
>>should just do what I expect, go to that other text, and shouldn't mark
>>the other text first and require me to hit "edit" before I can change
>>it. On the other hand, if I include a small icon in my text, I might not
>>want that: I might want to treat the icon just like a character in my
>>text, instead of "jumping right into it." The thing is that from there,
>>hitting the Right cursor key might not get me out of the icon, but move
>>my cursor INSIDE the icon somehow -- not exactly what I desire.
>>
>>First, I would say that when a thing is currently editable, then the
>>view's cursor accurses a cell inside that thing; if a thing is accursed,
>>but not editable, then the view's cursor accurses the handle of the
>>thing, not something inside the thing itself. This has complex
>>implications for cursor-centric views, though. It is probably necessary
>>to have a second cursor when in editing mode, an edit cursor. For
>>example, we might have a text vstream thing, and we might put a handle
>>to it somewhere. When we go to the handle cell (which shows the vstream
>>as a whole) and hit the edit key, the handle cell with the vstream gets
>>editable. We have an insertion cursor. But this insertion cursor needs
>>to be inside the vstream! Still, the view should be centered on the
>>handle cell. We want to see the outside of the vstream, not its inside.
>>
>>So, during editing, I suggest we have a second cursor, the insertion
>>cursor or more generally edit cursor. This cursor is inside the thing
>>that is currently edited. This thing gets all key events -- actually,
>>the viz that has drawn the thing on the screen is called for a list of
>>key bindings, which are then interpreted by gZZ. There's one exception,
>>the ESC key (or something similar), which escapes the editing mode.
>>(Another key might be specified for this in the system configuration,
>>but it is important that this key overrides all thing-specific key
>>bindings.) When the edit cursor is moved inside the thing, now, and
>>"hits" a subthing, the thing decides if it is "given" to the subthing,
>>or if the thing wants to keep it. If the latter, hitting TAB or some
>>other key specified in the thing's key bindings will give the edit
>>cursor to the subthing, making it editable. (Hitting TAB when the edit
>>cursor is not on a subthing's handle should give the edit cursor back to
>>the next higher thing, positioning it on the handle for the current
>>thing, making the current thing non-editable.)
>>
>>Something I would like are menus specific to the thing currently edited.
>>When I edit a text vstream, the menu should show a cut command; when I
>>edit a figure, the menu should show an insert circle command. The menu
>>should always be the context menu for the thing that has the edit
>>cursor. How the view presents the menu to the user is the business of
>>the view; which cell is the beginning of the menu is the business of the
>>thing's viz.
>>
>>The beauty of the "everything is a thing which can be visualized" system
>>is that it unifies applitudes much more than OLE could ever dream of. It
>>also makes currently existing and planned applitudes easier to
>>implement, because it boosts reusability. And, to me, it seems to be
>>very consistent with the overall ZZ philosophy.
>>
>>I'd greatly appreciate discussion! ;)
>>
>>
>>
>>SPECIFICATION
>>
>>SPEC (Visualization): A viz extends a viz type (abstract class which
>>implements ZZVisualization). It has a constructor which takes as an
>>argument the "thing home cell" (see below) it shall visualize as its
>>only parameter. 
>>
>>SPEC (Visualization type): A viz type is an abstract class which
>>specifies an interface for visualizing a thing -- e.g., the box viz type
>>specifies a function which is called with a ZZGraphics object and the
>>boundaries in which to layout. The viz type class contains a static
>>final member of type Class, called viztype, which is set to the viz type
>>class itself; this way, the viz type of subclasses can be found out quickly.
>>
>>SPEC (Visualization converter): Like a visualization, but takes a viz of
>>a different viz type as the parameter of the constructor. Masks the viz
>>it gets at initialisation. Has a static final member "fromviztype,"
>>which is like viztype, but specifies the viztype the constructor takes
>>as its argument.
>>
>>SPEC (Naming convention): It is recommended that viz type class names
>>have the form ZZ<TypeName>VizType and individual vizzes have the form
>>ZZ<ThingName><TypeName>Viz, for example ZZCellBoxViz for the box viz of
>>a cell. Inner classes may leave the zz out, and, when it is clear to
>>which thing type they belong, even the thing name; a module only dealing
>>with text vstreams may just have a BoxViz inside, because its clear that
>>the box viz for a text vstream is meant.
>>
>>SPEC ("Thing home cell"): This is the "first" cell of a thing. This is
>>given to a viz at instantiation, and it also is used to determine a
>>thing's possible visualizations.
>>
>>RATIONALE: Why don't we use the handle? Because the handle is not the
>>thing itself; it is a cell that contains the whole thing.
>>
>>SPEC (Handle): The original handle of a thing is connected to the "thing
>>home cell" on d.handle. The thing home cell is the negward neighbour of
>>the handle. The handle cell has no posward neighbours on this dimension.
>>All clones of this original handle are considered handles of the same thing.
>>
>>SPEC (Visualizations for a thing): From the "thing home cell", go to the
>>posend on d.visualization. From here posward on d.visualization-set (or
>>d.2?) is the list of possible visualizations. Empty cells are ignored;
>>if a cell except the first one is connected along d.visualization, count
>>the visualization set at the posend of that rank as visualizations of
>>the thing, too. Each visualization is represented either in the form
>>"ClassName," where the class with this name resides in fi.iki.lukka, or
>>"ModuleName.InnerClass," where the module resides in fi.iki.lukka.module
>>and InnerClass is a static subclass.
>>
>>RATIONALE: It is expected that applitudes will connect all things of the
>>same thing type, i.e. the same internal structure, on d.visualization.
>>If they want to group visualizations, they can use the recursive
>>structure which goes along d.visualization, again.
>>
>>RATIONALE (Reference by string): This probably ought to change at some
>>point, but it's consistent with the rest of the system right now.
>>
>>SPEC (Viz searching function): This function (residing SOMEWHERE, maybe
>>ZZUtils) finds the best viz of a given type for a given thing. It starts
>>with the posend of d.visualization from the "thing home cell", and
>>progresses on d.visualization-set (or d.2?). If it finds a cell with a
>>posward connection on d.visualization-set (d.2), it uses the same
>>algorithm recursively on the posend of that rank. The first viz whose
>>viztype member equals the requested viztype is returned. If no viz
>>matches, the viz convertion search is invoked (see below). If there
>>still isn't any match, null is returned.
>>
>>SPEC (Viz conversion search): In the system configuration, there's a viz
>>conversion list listing viz convertion classes, which are referenced in
>>the same way as the viz classes for things. Some efficiency hack ought
>>to store this converters internally. Now the "shortest path conversion"
>>is searched: preferably only one conversion, if necessary two, if that
>>doesn't work three etc. I'm sure you can come up with a better internal
>>algorithm for this that I.
>>
>>"SPEC" (Drag&Drop events): This should be consistent with the existing
>>flob code, which I'm not familiar with. Drag&Copy events (commonly
>>invoked by Shift-Drag) on a thing clone the handle of the thing. (The
>>dragItem is always the handle, the thing's "outside," not its "inside.")
>>
>>SPEC (ZZBoxVizType, rectangular view viz type): This should have a
>>raster method taking ZZGraphics, x, y, prefwidth, prefheight, maxwidth,
>>maxheight parameters and returning the width and height actually used
>>(which may not be bigger than maxwidth and maxheight, even if the viz
>>has to be clipped.) The different width and height parameters can be set
>>to -1, which means "any width" and "any height;" but not both the
>>prefwidth and prefheight parameters may be set to -1. The max parameters
>>may be omitted (in which case the same function is called internally,
>>with maxwidth and maxheight set to prefwidth and prefheight). The pref
>>params mean "preferably not greater than."
>>
>>RATIONALE: This is intentionally very open, as basically *everything*
>>should be optionally layoutable in a rect. The "not both prefs -1"
>>constraint is used for everything arbritarily scaleable, like vector
>>graphics. If you have a vector graphic with a width/height ratio of 2
>>(i.e., two times as wide as high,) and get a prefwidth or prefheight,
>>you can layout the stuff (and if the computed width or height is greater
>>than the maxwidth or maxheight, you layout it smaller). If you have *no*
>>values given (-1 -1 -1 -1), you can't layout the vector graphic, because
>>it has no intrinsic size. If your thing has a fixed width and height, on
>>the other hand (like bitmaps), you'll probably ignore prefwidth and
>>prefheight, and only scale or clip if maxwidth or maxheight are smaller
>>than your pic's w or h. -- You might also decide that it doesn't make
>>sense to layout this pic this small, in which case you return {0, 0}.
>>This is helpful when things are very "deep" inside the screen.
>>
>>CONSIDERATION: An optional "lighten" parameter might be useful, which is
>>a fraction range 0 to 1; if it is one, an empty box is drawn. This would
>>be used for the vanishing rasters.
>>
>>"SPEC" (ZZTextVizType): This should use the existing LineBreaker etc.
>>stuff, with witch I'm not yet familiar, as mutch as possible.
>>
>>SPEC (Edit cursor): A view which is in editing mode has an edit cursor
>>which accurses a cell inside the thing that is currently edited. For
>>efficiency, edit cursors (and edit cursor stacks, see below) may be
>>implemented virtually; this needs some modifications, but these should
>>be straight-forward.
>>
>>SPEC (Edit cursor stack): Every time the edit cursor is given to a
>>subthing, the old edit cursor is put on an edit cursor stack. Each view
>>in edit mode has an edit cursor stack (which might be empty), a common
>>list of cursor-cargo cells. When the edit cursor is given to a subthing,
>>the subthing viz is called for a new edit cursor, returning its cargo
>>cell; this is attatched in place of the old cargo cell, which is
>>inserted on top of the edit cursor stack. When the edit cursor is given
>>back to the next higher thing, the current edit cursor is destroyed and
>>the last edit cursor is popped from the edit cursor stack. If there is
>>no older edit cursor on the stack, the view quits editing mode.
>>
>>RATIONALE: A thing can have many handles (when cloned), and more than
>>one of these handles might be placed on the same screen. For example, I
>>could clone a figure two times in a thing cloud. Now, when the edit
>>cursor is inside that thing, which of the clones on my screen do I edit?
>>Oh, possibly I could show the insertion cursor in each one of them, but
>>when I quit editing the figure, to which higher-level thing do I give
>>the edit cursor back? To the one from which I reached the thing, of
>>course, and keeping track of this is the responsibility of the edit
>>cursor stack.
>>
>>SPEC (Requesting edit cursor): A viz may or may not accept the edit
>>cursor. If it does can be found out by calling its boolean
>>acceptEditCur() method. If it accepts the cursor, ZZCursor getEditCur()
>>can be called, which creates a new edit cursor inside the thing. A viz
>>type might specify other parameters to call getEditCur with; for
>>example, ZZTextVizType specifies getEditCur(int pos), so that the edit
>>cursor is positioned at the beginning when the insertion cursor comes
>>from the left, and at the end (-1) when the insertion cursor comes from
>>the right.
>>
>>SPEC (Requesting menu cell): To get the start cell of the thing's menu,
>>the ZZCell getMenuCell() method is called. It may return null, in which
>>case the thing doesn't have a menu. Menu cells may be requested only if
>>a viz accepts the edit cursor.
>>
>>SPEC (Requesting key binding lists): A viz must define a method ZZCell[]
>>getKeyBindingLists(). The cells returned by this method are the starting
>>cells of key binding lists (the events are found poswards on d.2, and
>>the corresponding actions are found poswards on d.1 from the events).
>>The key binding lists are used in order: if the event isn't found in the
>>first list, the second one is searched, then the third one etc. Key
>>bindings lists may be requested only if a viz accepts the edit cursor.
>>
>>SPEC (Requesting sub viz): To request the visualization of a subthing
>>inside the thing of a visualization, the ZZVisualization
>>getSubViz(ZZCell handle) method is used. The handle given is the handle
>>for the subthing, which must be placed inside the thing.
>>
>>RATIONALE: When the view wants to request the menu cell or key bindings
>>list of the thing its edit cursor is in, it needs to call that thing's
>>viz. Because the sub vizzes are generated by the higher-level vizzes to
>>visualize their thing's subthings, the higher level vizzes need to be
>>called for the lower-level vizzes.
>>
>>SPEC (Finding the viz associated with the edit cursor): Start with the
>>highest level viz as the current viz. For every handle accursed by a
>>cursor on the edit cursor stack, starting with the first item put on the
>>stack: call the getSubViz method of the current viz with this handle.
>>Set current viz to mean the viz returned by getSubViz.
>>
>>
>>
>>
>_________________________________________
>Theodor Holm Nelson              
>Project Professor, Keio University SFC Campus, Fujisawa, Japan
>Visiting Professor, University of Southampton, England
> ?  e-mail: ted@xxxxxxxxxx   ?  world-wide fax 1/415/332-0136
> ?  http://www.sfc.keio.ac.jp/~ted/    ?  http://www.xanadu.net
> ? Coordinates in USA      Tel. 415/ 331-4422
>  Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
>_________________________________________
>
>
>
_________________________________________
Theodor Holm Nelson              
Project Professor, Keio University SFC Campus, Fujisawa, Japan
Visiting Professor, University of Southampton, England
 ?  e-mail: ted@xxxxxxxxxx   ?  world-wide fax 1/415/332-0136
 ?  http://www.sfc.keio.ac.jp/~ted/    ?  http://www.xanadu.net
 ? Coordinates in USA      Tel. 415/ 331-4422
  Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
_________________________________________