Embedded Links, SALT Talks Stage I

[Marc Stiegler <marcs>]

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 
many documents.

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 
problem.

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 
reasons.

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?

--marcs