From: Eric Armstrong <eric.armstrong@eng.sun.com>
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
misspelling.
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=" http://clickme.onelist.com/ad/NextcardCreativeCL ">Click Here</a>
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:41 PDT