Link Behavior Questions

[Marc Stiegler <marcs>]

I am currently thrashing with the issue of whether links should 
be independent, first class objects like documents, or whether 
they should be embedded components of documents. Be aware that 
my mental model of links has treated them as first class objects 
since before I encountered the term "hypertext". As a consequence 
I must confess that my search for the best choice (first class 
or embedded) sometimes looks like an attempt to find a fundamental 
problem with embedded links, if only because I don't relish explaining 
to users the subtle pros and cons of choosing to embed a particular 
link behind Doc Number 1 or Doc Number 2. 

Anyway, I have tentatively identified the following differences 
between embedded the links and first-class links:

1)If embedded, the link falls under the version control of the 
document.

2)If embedded, the link falls under the permission control of 
the document.

3) If embedded, the link is more likely to be fetched without 
another disk access, since it is so conceptually close to the 
document that it is easy to lay the link physically close to 
the document on the disk. Since, on the average, half the links 
on a document would be embedded, this would cut in half the number 
of links for which a fetch might be required.

For reasons that I'll explain another day, I'd be happy to have 
the links fall under the permissions control of the document, 
but unhappy to see them fall under the version control of the 
document. So permission control is a vote for embedded links, 
version control is a vote for independent links. 

The performance issue is probably the driver here, if it is true 
that embedding the links might cut in half the number of fetches 
associated with a document. This is a big vote in favor of embedded 
links. However, I have a couple of other questions which may 
drive the decision even more strongly. Let us examine the following 
scenario:

Mark creates document A1. He attaches a link-activated sensor 
to the whole document. He creates derived document A2, i.e., 
A2 starts life as a vcopy of A1, and only unimportant edits are 
made to it. Now Mark runs a link from A1 to document B, with 
the link embedded in A1. He also runs a link to document C from 
A1, with the link embedded in C. Finally he creates more derivative 
documents from A1, documents  A3 and A4.

Questions I would like someone (markm or Dean, I guess) to answer, 
either because I have no idea or because I'm not sure enough 
of my analysis:

1) We do a backfollow from B. How many links do we find?

2) Eric runs a link to A3, with the link contained in document 
D. How many sensors ring?

(uh, make that "how many recorders ring?" If these puppies still 
do the things I understand, shouldn't they still be called sensors 
for the end user? I will use the term "recorder" for the moment, 
to avoid distracting one of the key Answerers Of These Questions).

3) We restrict the permissions on A1.  A person with read access 
to A3, A4,  and C backfollows from C. How many links do we find?

4) We attach sensors to documents B and  C. We create another 
derivative document A5. How many recorders ring?

DISCUSSION OF ANSWERS

Markm, dean, if you plan to answer the above questions, you should 
try to formulate the answers before reading the following discussion. 
However, if you need clarification of the issue at hand, here's 
my analysis:

1) Two views of how many links you get backfollowing from B seem 
possible: either there are 3 links, one each embedded in A1, 
A3, and A4, or there is one link that terminates in 4 contexts 
(the 4 contexts include A2, since the link ends on text in A2, 
though the link is not contained by A2). 

It is not clear to me that we would be doing the user a favor 
by showing him 3 separate links, each of which ends with the 
same 4 different contexts, even though the default context for 
each of the 3 is different (uh, as I think about it, since the 
default context is also vcopied, they all share that, too!). 
Indeed, it is my strong opinion that this would be a very hostile 
thing to do to a user. 

I would like to represent all these identical links using a single 
viewing mechanism. Though we may pick a better mechanism, we 
currently achieve this by showing a single link in the link pane 
with a single default context, and letting the user select a 
non-default context if he so desires. If the three links appear 
as separate items in the link pane, it's real boring--the only 
discriminator among them is the bert name of the container.

Please note, those readers who don't like link panes anyway, 
that the problem is more fundamental than the link pane representation.

2) When the link goes to A3, I hope one recorder rings, the recorder 
that was copied along with A1 when A3 was created. It would be 
a real bore if recorders rang in A1 and A4 as well because the 
link was attached to text inside their text space but outside 
their context. It would be acceptable, even reasonable, if the 
recorder didn't get copied from A1 to A3 and no rings occurred 
at all. 

Actually, a more correct model of the behavior I would like is 
that there is conceptually a single recorder attached to all 
these vcopied documents, and a link to any document sets off 
the single recorder. If I understand the system correctly, this 
actually is how it would work, but I figured I better check.

3) Though the permissions on the original document containing 
the link no longer allow access, I would like to find 1 link 
with 2 bert contexts, A3 and A4 (and perhaps A2, depending on 
whether the reader has permission on it, of course).

4) I would like to have no link-activated-recorder rings go off 
just because someone vcopied a document. In vcopying the document 
containing a link, are we creating new links for every link embedded 
in the document? This would set off a huge number of recorders 
if someone embedded a link in a document that many people used 
as a template. 

Of course, it would be a silly error to put a link in a template 
document, but it would be an easy mistake to make, particularly 
if Xanadu is successful, and all documents wind up being used 
more often as templates. 

To understand the depth of my concern, please realize that I 
expect people to put recorders on almost every interesting thing 
they read, and on virtually everything they create. If vcopies 
of documents cause link-activated recorder rings, people won't 
be able to do this: the noise level would be horrendous. 

In all these situations, first-class links give us the behavior 
that seems most appropriate to me, if I understand how first 
class links would work (which is in itself questionable). We 
could implement first class links with a minimum of modifying 
the backend by creating a new document for each link. This creates 
more overhead for the link but I don't find that very disturbing. 
However, the potential performance loss is disturbing.

I have a few words in response to Greg's concern about overhead 
in another message. 

--marcs