Re: [unrev-II] thoughts on editability

From: Eric Armstrong (
Date: Sun Jan 30 2000 - 22:00:56 PST

From: Eric Armstrong <>

Jeff Miller wrote:

> 1. notes vs changes

Yes. We need to keep that distinction in mind.
See response to Point 2. As for links, see response to Point 3.

> 2. local vs global availability
> With an intermediate server it would be possible to edit documents
> that you don't have authorship rights to.

It struck me today that a two-tier system might be valuable.
One tier would be the email archive, containing all discussions.
(An "additive" archive, if you will.)

The second tier would exist independently, as a "reductive" layer.
The editing process would allow you to trim the fat from responses,
make edits, write summaries, "delete" items (from the current view,
not from the archive), and rearrange order. Links to the original
entries would be automatically maintained.

The second layer would consist of editable "documents". When
posted to the mailing list, they would become part of the archive,
with the ability to collect responses. Copying the email version
from the email archive into the document archive might then take
all of the responses it had collected along with it, where further
edits could occur.

The trick is figuring out what to do with email responses that
arrive after you begin editing... Any ideas?

> 3. maintaining link validness

This is a key issue, especially in a hierarchical system. Nodes
can change position, have contents changed, or be deleted.
What becomes of links to those nodes?

One part of the solution is node IDs. That takes care of nodes
that move to a new position. Performance is still an issue, but
those concerns are probably addressable with a good design.

Another part of the solution may be two-way links. If every
link to a node has a corresponding link back to the origin of
the link, it is possible to:
   a) Identify nodes that have no links, so they can simply
       be removed
   b) Maintain a "phantom node" that displays as strikethrough
        text and a message "This node was deleted" when a
        link is traversed.
    c) Place a mark in the initiating document that indicates
        "this node is invalid" and/or send a message to the
        owner of the document.

Two points here:
   1) With a two tier system, the problem is ameliorated, since
        links to archived items will always be present.

    2) Maneuver "c" above may well be sufficient for the remainder
        of the cases. The problem with invalid links, after all, is that

        they look fine until you traverse them. Since you can't tell
        they're bad by inspection, they tend to sit around longer than
        they would otherwise. (If they "smelled", they would be
        found and fixed sooner.)

       Also, from a user-interface standpoint, knowing that a link is
       invalid makes it something easy to ignore. It's like a
       The document would be more "professional" without, but it's
       easy to overlook. From the user perspective, the only thing
       troublesome about bad links is that they masquerade as good
       ones, so marking the original as invalid may well be a totally
       sufficient solution.

The only remaining issue is links to thinks in which the contents
have changed. The same thing happens when you link to an
anchor that was left in a document, but the document was
reorganized and no longer reflects the original information.

Cutting and pasting text from a node in hierarchical system could
have the same effect -- a link might point to a node whose
contents are no longer appropriate. I suspect we just have to live
with that one. I don't see a really good solution for it. In such
a case, the link would still be "valid", but meaningless. (Again,
if most links go to the email archive, rather than the document
system, the problem is ameliorated.)

--------------------------- ONElist Sponsor ----------------------------

GET A NEXTCARD VISA, in 30 seconds. Get rates as low as 0.0 percent
Intro APR and no hidden fees. Apply NOW.
<a href=" ">Click Here</a>


Community email addresses:
  Post message:
  List owner:

Shortcut URL to this page:

This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:41 PDT