MultiBert EndSets

[Mark S. Miller <mark>]

Abstract: We wrestle yet more with referencing vs containment and what
it means for context information stored in link ends.


   Date: Mon, 13 Nov 89 10:08:22 PST
   From: marcs (Marc Stiegler)

   Precis: The inclusion list makes it easy, and inevitable, that 
   people will create endsets for which there is no single bert 
   that contains the entire endset. As nearly as I can tell, the 
   current document design assumes a single containing bert. Do 
   we have a problem here?

No.  The currently implemented design does have this restriction, but
we've known for a while how to extend it such that a Link EndSet can
contain multiple Ends.  This is also the terminology we've been using
lately: a single End can only designate a single bert context, but a
link has (for example) a "from" EndSet which will eventually be able
to have multiple Ends.  The proposal to "Stamp Out PartKeys" (which is
really a proposal to give Orgls StampIDs) may result in unifying Ends,
Context Path Trees, and EndSets.  A multi-End EndSet would just be a
Context Path Forest.  This idea isn't clear yet.  When would you need
multi-Ended EndSets?  I'd like to postpone them for a while.
(especially until we have the time to think through "Stamping Out
PartKeys")

   ----

   Ever since the discussion of embedded and standalone links, I've 
   fired an occasional neuron worrying about the bert context mechanism 
   for picking an endset, and its possible failures (starting 
   with my desire to remember the bert of the inclusion list which 
   was the context for a referenced document, so that when the link 
   to the referenced document is traversed, we get not merely the 
   document itself, but also the inclusion list it was  being viewed 
   within at the time of link creation).

Structurally, the link End context information is able to represent what
you have in mind here without extension.  You would just specify as
bert context the bertID of the inclusion list itself, and treat the
bertID of the referenced document as a part key in the context path
tree.  The context path tree would therefore span from the inclusion
list bert down thru the inclusion structure (probably only the one
path), hop over to the referenced document bert, and continue down all
the way to the referenced material.

However, even though this would structurally make sense, it is *not*
supported by our docs and links code.  Both the creation of the
link-end, and the following of it, would have to be specially done for
inclusion lists.  The normal End creation and follow code assumes that
context is within a single work.  This assumption is based on the way
I've been conceiving of reference vs containment:

If A refers to B, and you get to B to traversing to A, A was just a
navigational aid.  Once you get to B, B is all the context there is
for where you are.  As someone once said, "wherever you go, there you
are!".  If on the other hand, A contains B, then when you are at B,
you are there *within* A.  A as context has two related implications:
changes to B are also changes to A (and version tracked as such), and
when a link is made to material in B, A is designated so the link can
later be followed into it as the proper default viewing context.  I
don't think either of these are particularly controversial (well, as
things go around here anyway ;-)).

The novel problem triggered my you email message is how to regard the
referencing relationship.  If A refers to B, and we got to B thru A,
it is still certainly the case that A isn't changed when B is.  That
is what we *mean* by referencing.  What you are suggesting is that A
still be viewed as context information for the purpose of making and
following link Ends.  This is novel.  It is clear that we could not do
this in general, because a typical session may consist of browsing
around a system for hours following referencing relationships.  When
we then make a link to something, we clearly do not intend for the
system to store the entire navigational sequence we used to get to the
linked material!

What this shows is that there is more than one kind of containment,
and the inclusion list forces consideration of an interesting
intermediate case.  On the one hand, the inclusion list wishes not to
history track with referenced parts (in order to prevent coorperating
users from accidently forking parts when they don't intend to).  On
the other hand, the inclusion list is clearly a presentationally
"containing" context for the material to be viewed in.  Following Alan
Kay's dictum about "similar things", I'd sure like it if both of these
distinctions could be made the same or, barring that, completely
different.

We could make historical-containment and End-context-containment the
same in several ways.  If we do make them the same, I suggest a simple
visual rule that should make the behavior of the system *much much*
clearer and explainable.  (This visual rule evolved significantly
during a discussion with Dean.  Several of the ideas in the rest of
this message are also due to that discussion.)  The rule is that
spatial containment on the screen should exactly parallel internal
containment.  If A contains B, then when viewing B, there is a some
area connected to it which is visually around it (or, at least,
connected to it either to the left or above) which represents A.  If A
and B are not in the same work, then either they are spatially
separated on the screen, or they are visibly separated in the Z plane
(i.e., there is visible overlap, and preferably a shadow too).

This rule would be clarifying because you could say a) when you change
something, that which spatially contains it changes to, and b) when
you link to something, he who later follows your link will see the
material inside the same spatial container that you are currently
seeing it in.  Being able to cue both of the subtle notions off of one
concrete physically understandable visual rule is quite attractive to
me, and may outweigh many costs.

When can achieve this unification is several ways:

1) We could say that inclusion lists are containment only.  This
doesn't make the world containment only--links still connect things by
reference (independent of how the standalone links discussion goes).
If you want an inclusion list header to refer to something, do it with
a link instead of the header-to-part-document attachment structure (I
don't know what this is called).  The cost is, we would give up on
shared access to visibly changable parts in a lightweight way from
different inclusion lists (i.e., the part documents would fork too
often).

2) We could leave the current inclusion list structure alone: Have it
able to decide on a header by header basis when it is containing a
part and when it is referencing a part.  And leave the current
docs&links layer rule for forming and following Ends alone: When you
link to stuff in a referenced part, only that part is remebered as
context.  When you link to stuff in a contained part, the entire
inclusion list is remembered as context.  We would supplement this by
the above visual rule as follows: When the left window contains the
inclusion list and the right contains a part, if the part is contained
then the windows abut, else there is a sliver-gap between them thru
which the desktop background is visible.  When you do a contiguous
sequence parts expansion, there is a tall thin strip on the left which
represents the inclusion list itself.  Each part is in its own almost
full-width window.  If a part is contained, then it abuts the strip.
If a part is referenced there is the same kind of gap.  In addition,
there is a horizontal sliver-gap above and below every referenced
part.  The user can indicate his choice about whether a part should be
referenced or contained by whether to "dock" it against the inclusion
list.


Looking at the other side of Alan Kay's dictum, we can make these
completely different with the following generalization: The reason the
inclusion list as context is important is because that was what the
user was looking at at the time he made the link.  Well it isn't all
he was looking at.  We already have a notion of "TableTops" (a set of
windows with positions and contents).  Let's store (in addition to
current context info) the TableTop which describes the user's entire
xanadu desktop at the time the link is made.  Then we will reproduce
as much of this for a later reader as that reader has permission to
read.  I think Dean pointed out some fatal problem with TableTop End
contexts, but I can't remember.  (Dean?)  In any case, they don't seem
to be a good idea to me either, just intriguing.


Finally we can decide that these two kinds of containment really are
different.  This does not create four cases, only three--we outlaw the
case where A is history tracking context but not End-context.
End-context must be at least as inclusive as history-context, but may
be more so.  End context never preserves link-traversal history, but
does preserve the header-attachment structure (whatever that is
called).  Going this route produces the following great property:
Since we expect people to change their minds in a light-weight way
about whether a given inclusion part is referenced or contained, a
link made when the relationship was one way can still be validly
followed later the relationship is the other way.  This is quite
powerful.  If we do this, I still advocate the above visual rule be
used to indicate historical containment.  However, we would need an
additional rule for End-context-containment.  Perhaps an end-context-
container which is not an historical-container surrounds the part
without touching it?


P.S.  These visual rules are consistent with, and serve to make
explicit, the subtle fact that the outline hierarchy of an inclusion
list is not a fine-grained containment structure (since nesting boxes
aren't drawn).


P.P.S.  If we do end up deciding to mix together in the link-list both
links in this document and links whose home is elsewhere, we can use
the same spacial cue to indicate which is which:  The foriegn links
would be in their own box which has a gap all around it.  The links in
this document would be attached at least of the left.


I'm sleepy so I'll answer the rest of your message later.