[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Embedded Links, SALT Talks Stage I
- To: <xanatech>
- Subject: Embedded Links, SALT Talks Stage I
- From: Marc Stiegler <marcs>
- Date: Thu, 26 Oct 89 13:16:01 PDT
I met with dean for a couple of hours Tuesday to resolve
our differences on first class and embedded links. Sigh. Dean
still doesn't see it my way :-)
I am going to try to summarize the points upon which we did agree.
Such attempts are fraught with danger, as can be seen from my
last attempt to describe a set of things upon which we would
agree. However, you have to hit me over the head with a stick
more than once to make me stop. So here goes.
As of September 24, 1989, marcs believes that he and dean agree
on the following things:
1) If a document has an embedded link, and if many variations
of that document are spawned (i.e., multiple berts), there is
merit in allowing the user to see this as a 2-tier selection,
in which the user sees one link first, then chooses among the
2) It is reasonable in the first frontend for links created either
through endset pairing or through inclusion list pass-through
to be "first class", i.e., have their own permissions and their
own version control.
3) There is no known problem with having the link embedded in
the new document when a link is constructed using the "attach
new note" link creation mechanism in the infofactory, assuming
that the links are stripped out of a document when contained
into an inclusion list.
4) We do not yet know a reason why we could not strip out the
links of a document when contained into an inclusion list.
5) There is merit in having a version track on a link when people
start explicitly editing link ends.
6) There is sometimes merit in being able to perform version
tracking of a link with at least one of its endset documents
together. The obvious way of doing this is to embed the link.
7) If there is sometimes merit in having the link version track
with the documents at both ends of its link, it is an interesting
8) A document which version tracks a document network should
embed the links which are a part of its network.
9)I think we can generalize the point above in the following
way: if both the endsets of a link are found in the same document,
it is acceptable to embed the link inside that document. At least,
there are not currently any counterexamples.
10) There is merit in being able to filter for bert set, i.e.,
show me only those links whose far endset touches one of a list
of berts, i.e., show me only links that are connected to other
documents in a particular project. Given this as a filtering
criterion, the criticality of allowing 2-tier selections if the
link is embedded, gets reduced.
11) The current frontend does not make it easy enough to aggregate
documents by project to make this a reliable filtering criterion.
So at the moment we can't use bert set filtering to reduce the
criticality of 2-tier selection, even if I hadn't already thrown
bert set filtering into release 1.1 six months ago for scheduling
Interesting questions for further consideration include:
Is it compellingly important to allow the user to see a single
link embedded in many berts, as a two-tier selection process,
to the point where, if such two-tier selection is not supported
by the backend, first class links are the correct choice?
Is version control on a link really important at all unless people
are editing the endsets explicitly?
Do we have to create the interfaces and the explanations to allow
people to explicitly edit endsets for release 1.0?
Can we make embedded versus first class invisible to users so
we don't have to explain it?
Is it compellingly important to not have to explain embeddedness
to users in release 1.0?
Dean, what would you like to add to/correct in this?