zz,c.rel: ReRe Units and structures, more (was Re: [zzdev] A bigsuggestion

[Ted Nelson <ted@xxxxxxxxxx>]

Hi Benjamin--

I think we have very different philosophies, life agendas and
 computer religions.  (I wish I had time to write my planned book
 of that title.)  Nor do I have time to explain why I don't like object-
 oriented design or object closure.

Since this is LGPL open source, you're welcome to vary it
 any way you like.

My design represents my own religious principles.  Religion is beyond
 argument; the best outcome is to understand each other cordially.

All best, Ted


At 02:51 AM 8/4/00 +0200, you wrote:
>Hi Ted!
>
>You wrote:
>> 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.
>
>Note, here, that your examples are structures which can be reasonably
>viewed with standard zz raster views. I was more thinking about stuff
>like formatted text and pictures, whose structural representation in zz
>is much less close to the actual "meaning." 
>
>> 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.
>
>This is a point where my suggestion put a clear constraint. For a
>reason, though. We want to *combine structures* which have meaning only
>to *different applitudes*, don't we? Then, connection may not be
>arbitrary: when stuff of applitude 1 connects to other stuff on d.2, and
>applitude 2 lists its stuff as a looping rank on d.2, we're lost.
>
>> ? "Closure" is not required: structures may continue in any direction.
>
>The "thing" suggestion does not require "closure:" it requires *creating
>interfaces*. You can still link anything to anything.
>
>> ? Elements may be simultaneously in more than one recognized
>>  structure.
>
>This is useful when a user knows how two recognized structures work, and
>comes up with a clever way to interconnect them. By no means I want to
>limit that possibility; it is great. However, *using* a recognized
>structure does not necessarily mean *knowing how it works*. Note that
>I'm not talking about the easily representable stuff you mentioned; I'm
>talking about stuff like vstreams and cuts in them, and similar stuff in
>other applitudes; I certainly don't want to have *every* format some
>applitude I desire to use has internally. I do not want applitude
>programmers to tell me "you don't need to know my format;" but I don't
>want them to tell me "you need to know my format," either. I want to be
>able to re-use stuff across different applitudes without worrying about
structure.
>
>You could boil the thing idea down to:
>- attatch possible ways to recognize a structure to this structure
>- attatch a handle to the structure
>- have this handle presenting not a text (label), but an interpretation
>of the thing, generated by said possible recognition ways (for example,
>have the handle of a picture show this picture, while the actual
>structure the handle is connected to doesn't show pictures, but the
>parameters & stuff the picture is generated from)
>- allow clones of these handles which look like the handles
>- make it possible to put a thing (or rather, it's handle or a clone of
>it) EVERYWHERE: in the structure, in a formatted text, on an item cloud,
>into a picture, into a hyperflob (as to be moved along a path), etc. pp.
>Or in a sound vstream, when we're talking about things interpretable as
>a sound.
>
>Note that you can put things in different places by cloning their
>handles. Also note that the words of mine you seem to dislike that much
>-- encouraging applitude programmers to split up stuff into things --
>was intended to get BETTER REUSABILITY without having to learn the
>applitude-specific structure: so that you can use a graphic primitive
>designed for one applitude, and just put it into the
>hypertext/hypermedia doc you create (mostly) with the tools of another
>applitude. This should be a trivial operation, without having to pay
>thought to internal structures; and only making such actions trivial and
>fast will, I believe, truly make applitudes ZONES OF FUNCTIONALITY which
>you don't have to use as a whole, but whose parts you can freely re-use.
>
>You could also say: Everytime you make something stuff of *your*
>applitude can be put into (arranging it in some way), make sure that 1)
>stuff from other applitudes can be put there as well, and 2) the stuff
>from your applitude that can be put there can also be put into stuff
>from other applitudes. Ya know what I mean?
>
>> All best, Ted
>
>Oh, and I shall tell you greetings and good luck with your projects from
>my mother; we talked about Xanadu (and a bit about ZZ) today and she got
>quite excited about it, even the basics: "You mean I could go from the
>citation in my letter to the original without even having to enter the
>page number?" "I could just 'switch off' my comments for the next person
>to read, and then switch them on again?" Her books are always full of
>comments and side-notes. "Does that exist already?" -- I know you've
>heard that a lot of times, but I figure it's still nice to hear it. ;)
>
>- Benja
>
>
_________________________________________
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
_________________________________________