Date: Thu, 10 Feb 2000 14:37:57 -0800
| From: | Eric Armstrong |
|
eric.armstrong@eng.sun.com Reply-To: unrev-II@onelist.com |
| To: | unrev-II@onelist.com |
| Subject: | OHS: Functional Overview |
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.
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.
The remainder of this post discusses the various operations that go in such a system, namely:
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.
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.)
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.
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 drag 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.)
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.
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.]
When a new version arrives, the changes are applied to the original. As a recipient, you can register interest in:
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.)
Eric Armstrong
eric.armstrong@eng.sun.com>