From: "John J. Deneen" <jjdeneen@ricochet.net>
Hi- David,
Last Tuesday, I introduced to the members of the "Unfinished Revolution"
colloquium with Doug Engelbart at Stanford University a brief background of
Netsystem/NetForum for virtual high-performance team applications. Can you
contact Doug to discuss and demostrate how it relates to his Open Hyperdocument
Systems (OHS) enabling technology ? Also, is there a way we can contact Barbara
Davis for inviting her to join the colloquium ?
Thank you,
John Deneen
(925) 229-1858
Bootstrap Institute
6505 Kaiser Drive, Fremont, CA 94555
Phone: (510)713-3550 Fax: (510)792-3506 Email:
info@bootstrap.org
Website: http://www.bootstrap.org/
Eric Armstrong wrote:
> 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
--------------------------- ONElist Sponsor ----------------------------
Get what you deserve with NextCard Visa. Rates as low as 2.9 percent
Intro or 9.9 percent Fixed APR, online balance transfers, Rewards
Points, no hidden fees, and much more. Get NextCard today and get the
credit you deserve. Apply now. Get your NextCard Visa at
<a href=" http://clickme.onelist.com/ad/NextcardCreative1CI ">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