Embedded Links, SALT Talks Stage I

[Eric Dean Tribble <tribble>]

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

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

Yup.  Examples?  Marcs suggested looking at Joel's presentations for
examples. 

   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 
   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?

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?

Don't know.

   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.

dean