Draft Treaty On Links

[Eric Dean Tribble <tribble>]

Anyway, to me it appears that embedded links add noise to the
   problem of picking the right bert context, rather than solving it.
    This is one of my major complaints about embedded links (it adds
   noise in that you wind up with 3 representations of the same
   link, a link that has 4 contexts you might want. And none of our
   current filtering criteria can select them down to 1).

No.  Embedded links make the problem clearer.  I can just imagine
getting the frontend out there without having considered this problem,
even if all Links had their own works.  

The problem of managing replicated Bert contexts is a problem that
requires a solution.  Let us STOP considering it only in the light of
embedded vs standalone links.  I propose addressing it in the context
of embedded links just because a correct solution will be more
obviously correct.  (This is one of the extraordinarily successful
Xanadu design strategies).  AGREED?

Following links only to a particular project patches the problem with
a solution that doesn't scale.  What does a scaling version of this
look like?  Nested projects, perhaps (DAG rather than hierarchical).
I wonder if the inclusion list interface has any useful extension in
this direction.

   However, I've not thought of a way of implementing projects
   that doesn't depend on mind reading--it requires that the 
   user tell the software about it when the user changes projects.
   I consider such a mechanism to be just too unreliable.

The original version of my Smalltalk project manager had similar
problems.  The user could choose from among several projects.  All
changes to Smalltalk code were recorded in the current project.  I
constructed this in a fit of desparation because I was working on too
many things in Smalltalk.  I would inevitably get bitten because I had
made changes to one project within another (fix an Iterator bug while
working on the Ent) - very frustrating.  The current version mostly
fixes this by associating particular classes with particular projects.
Now, any change I make to Iterators go in the Iterator project, even
if I'm working in another project.  Newly added classes go in the
current project.  Changes to 'unowned' parts of the system go in the
current project.  I have been continually surprised at the
effectiveness of this fix.

The equivalent of my solution for the frontend is to use connectivity.
A derivative of another document goes in the same project as that
document.  A note on another document goes in the same project.
Creating a new sub-document in an inclusion belong to the inclusion
list's project or to the current project.  We can think about other
solutions like changing the current project to the project of the most
recently selected document (wrong of course, but an interesting
direction).

dean