From: Eric Armstrong <eric.armstrong@eng.sun.com>
This post takes a look at how a system which integrates
email and document management would work. If we agree
that the system has to operate in this way, we can proceed
with a more detailed functional spec, and then design.
On the *other* hand:
* The system developed below seems pretty complex.
Is there any way to simplify it?
* Is there any way to use existing tools and applications,
rather than writing everything from scratch?
Summary
-------
The Open HyperDocument System (OHS) that serves as precursor to a
true Dynamic Knowledge Repository (DKR) will need to integrate
email and document management into a smoothly functioning whole
that has not heretofore existed (except, I suspect, within the
framework of Augment).
To do so, it will need to combine hierarchical structuring,
document linking, versioning, differencing, and author-attribution.
Functional Overview
-------------------
The remainder of this post discusses the various operations that
go in such a system, namely:
* Authoring Documents
* Receiving Documents
* Browsing Documents
* Responding to Documents
* Receiving Responses
* Revising Documents
* Receiving New Versions
* Backpedalling
Note:
I am still presuming XML as the underlying implementation.
To keep the design space open, though, for "XML" read
"hierarchical, document storage mechanism with robust linking
capabilities".
Authoring Documents
-------------------
You are working in an XML-editor of some kind, operating on a
hierarchically
structured document to which you can add links. Every change you make
is time-stamped or given a unique internal version number. Every node
you create lists you as its author.
At certain points, you may "revmark" or "checkpoint" the document,
to fix an externally visible version number (e.g. 1.2). An "undo"
operation lets you take back changes to the start of the version.
A "prev version" operation lets you go back to an earlier version.
(You may or may not be able to undo the changes to that version,
depending on the implementation.) When the document is ready for
review, you post it to others.
Receiving Documents
-------------------
When you receive a new document, it is stored in your file system at
a location you have designated. It can then be treated like any other
read-only XML document on your system. (You can always edit a copy,
but the original generally remains untouched.)
Browsing Documents
------------------
As you browse the document, you can set bookmarks, flag sections for
comment or follow up, move to the next unread section, or go to one
the bookmarks you have set for that document.
The "bookmark" list only shows you bookmarks you have set for the
current document. A "reference" list also exists that shows you the
documents in the system, indicating which you have stored locally,
and which are not.
Responding to Documents
-----------------------
As you browse the document, you can respond to individual sections
in the hierarchy. The responses are not sent, however, until you
initiate the "post response" operation. All of your responses are
then sent as a single package, each response in it's own section,
with links to the original document hierarchy.
When you dragging a reference to the document or response you are
working on, a link to the document is created. The link is in the
form of a Universal Resource Name (URN) which resolves to the
copy on the recipient's system, if it exists. Otherwise, it resolves
to the unique URL from which the document originated. The "origin"
might be on the original author's system, or in some server
repository, depending on how the system is implemented.
When you open a reference, you can drag a bookmark to the document
or message you working on. A link to that section is then created.
You can also make "suggestions" by copying a section, and making
changes. The changes you make are automatically attributed to you.
You can then send the modified section as a suggested replacement
for the original. (Note: There are two types of suggestions. A
"shallow" suggestion is a suggested replacement for an individual
node. A "deep" suggestion is a proposed replacement for that node
and all of it's children. The system must understand the difference.)
Receiving Responses
-------------------
As responses to the original document are received, they are logged
in the "response list" section of the original hierarchy. Each
response is flagged as "unread" until visited. The "go to next unread"
function takes you to the next as-yet-unvisited response.
Revising Documents
------------------
As you work on new versions of the document, feedback on previous
versions is continuously available. If feedback arrives on a node
that no longer exists, the earlier version is displayed in gray,
with the version number visibly indicated. You can then chose to
copy the feedback to a new location &/or make it disappear, along
with the original node. (When you start getting a lot of these
artifacts, you know it's time to post a new version.)
As you make changes, you can reference responses you've received,
or use the "accept" operation to use a suggested replacement in lieu
of your original.
As an optional operation (depending on the implementation), you
may choose to add additional authors to the authoring list for a
section. (For a deep suggestion that is accepted, the addition to
the authoring list may be automatic.)
An "additional" author is allowed to make changes directly anywhere
in the hierarchy stemming from the segment where their name appears.
Sometimes changes by multiple authors will overlap. The system
accounts for that by displaying all versions, allowing you to select
the version you want, and edit it.
When you are done making changes, the "post" operation delivers a
delta of the last posted version and the newest version to the
recipients. [Depending on implementation. This may be desirable,
or it may be better to redeliver the entire document.]
Receiving New Versions
----------------------
When a new version arrives, the changes are applied to the original.
As a recipient, you can register interest in:
* All comments
* All versions
* Latest version only
* None of the above
If you are interested in all comments, you see email traffic as it
goes by. If all versions, you keep both the latest and previous
versions on your system. (Or possibly one version and deltas.) If
"latest" version only, then deltas are applied and that is the
version you see.
All new sections are automatically marked as unread. That flag is
cleared when you visit the section.
Backpedalling
-------------
When you are added to an interest list late in the game, you may
receive "deltas" for a document you do not have on your system.
Or you may change your registration from "not-interested" to
"all versions", for example. In such cases, the system must deliver
the base version you need to operate from. [The implication here
is that the system needs to blur the line between email and serving
HTML pages.)
--------------------------- ONElist Sponsor ----------------------------
GET A NEXTCARD VISA, in 30 seconds. Get rates as low as 2.9 percent
Intro or 9.9 percent Fixed APR and no hidden fees. Apply NOW.
<a href=" http://clickme.onelist.com/ad/NextcardCreative4CI ">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:45 PDT