[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Link Behavior Questions
- To: <xanatech>
- Subject: Link Behavior Questions
- From: Marc Stiegler <marcs>
- Date: Mon, 16 Oct 89 15:00:17 PDT
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
2)If embedded, the link falls under the permission control of
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
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
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
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.