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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

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