[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Embedded Links, SALT Talks Stage I
- To: <marcs>
- Subject: Embedded Links, SALT Talks Stage I
- From: Eric Dean Tribble <tribble>
- Date: Thu, 26 Oct 89 16:03:46 PDT
- Cc: <xanatech>
- In-reply-to: <Marc>,01 PDT <8910262016.AA01180@xanadu>
I left points I agree with alone.
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.
It is tolerable. We didn't get to talk about alternatives. We should
be able control the default for each symbolic link type and be able
to edit it in particular for each link (in the link editor).
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.
Yes. There may be problems with stripping links out.
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.
More clearly, there is merit in having the link track versions with
the contents of its end when that end gets edited.
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
Yup. Examples? Marcs suggested looking at Joel's presentations for
8) A document which version tracks a document network should
embed the links which are a part of its network.
And should probably embed the documents as well.
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.
No. You might make lots of copies of the document and thus find lots
of copies of the link.
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?
Yes. The frontend may implicitly edit link-endsets when the user
edits the contents linked-to. These link-endsets should track the
text contents when the user changes versions.
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?
I think we can make it an advanced feature.
Is it compellingly important to not have to explain embeddedness
to users in release 1.0?
I think explaining embedding vs non-embedding is easy given compelling
examples of each. The concept of embedding is really pretty
straightforward. Therefore: no.