[unrev-II] DKR/OHS: 5 Authoring Requirements

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Sat Feb 19 2000 - 16:21:35 PST

From: Eric Armstrong <eric.armstrong@eng.sun.com>

Five fundamental operations the system must have...

1. Segment Collection
   It should be possible to specify a document you
   are working on as the "current target", and then
   roam through out the Document Repository, select
   text, a node, or a subtree and invoke one of the
   following operations:
      a) make reference
      b) copy

   The reference or copied text then appears in the
   target document. For the copy operation, both the
   copied text and the reference to where it came
   from are instantiated.

   After the reference/copy operation, the context does
   *not* switch to the target document. You stay where
   you are, so you can keep browsing and selecting
   additional items.

   As a side effect, setting the target document should
   mark that page so you can easily get back to it.

2. Context-Sensitive, Multi-Level Pagemarks
   The PageMark list should be context-sensitive and
   multi-leveled. When you access a document, the pagemarks
   in that document should be readily available. They
   may have been accessible in a hierarchy before, but
   they should now be readily available, and possibly

   There should also be a working list" of pagemarks.
   At a minimum, that list would typically consist of
   the target document for reference/copy operations and
   the document being read ("mined") for references.

   An easily-selected operation should allow cycling among
   entries in the working list, so you can rapidly change
   context between multiple documents you are working on.

3. Automatic Destinations
   When you are in a functional specification, and you create
   a design note, that "target" document for that note should
   be automatically determined by the current context.

   The implementation may use pre-specified target locations
   for nodes of a given type. For example, "design notes"
   for a given functional spec might go into a predefined
   "design document" hierarchy. Alternatively, the system
   might allow building preliminary document-versions using
   queries, like: "Give me all design notes that correspond
   to functional requirements in this version of the design

4. Automatic Linking of Typed Nodes
   When nodes are created, they are necessarily typed. The
   default for a new node is the type of it's parent. It
   then lives under that parent. For example, creating a
   new node under a functional specification heading produces
   a functional specification node.
   It should also be possible to create a node with a different
   type -- for example, when creating a design note. Links are
   then automatically created between the new node and the
   origin node, unless you specify "unrelated". (That lets you
   track random thoughts that occur to you and have them go the
   right place without a meaningless link.)

   It must be possible to easily see and select node types
   from the current context. Node-relations must be defined
   as well. For example, if you create a design note from a
   functional-spec node, the need for a link is defined by
   that relationship (unless you specify otherwise). On the
   other hand, if you create a personal-calendar node after
   receiving a phone call, the system should understand that
   the default in that case is "no link", unless you specify

   TBD: Should node types be pre-defined? If they are, it
   prevents one person from specifying "Design Idea" while
   another specifies "Design Note" or "Design Topic".
   Without that regularity, it becomes impossible to ensure
   that a query has accessed all the relevant information.
   On the other hand, on-going investigations into "wicked
   problems" may need to organize as they go. So it may be
   best to allow node-type creation on the fly.

   [If specified-targets are used to define "destinations",
   the system can ensure that a second type does not point
   to the same target. That is not a complete solution,
   since competing targets could be created. In that case,
   a merge operation might be a solution. It would need to
   a) put the two documents together and b) change all links
   of one type to the other type. On the other hand, if the
   query system is used exclusively to find related nodes,
   then there would be no checks at all on dynamically created
   node types.]

5. Drag and Drop Produces a LINK
   With a node-typing system comes the need to change a node's
   type. As the problem is better understood, thoughts originally
   captured in one venue will need to be retargeted for a
   different purpose.

   XML's entity references leap to the rescue here. (Unfortuantely,
   the term "reference" is a misnomer. Syntactically, there is
   a "reference" to another information node, but semantically that
   node is "copied" inline into the current document. So it's not
   a "reference" the way you think of a book reference. Instead,
   it's a "reuse" of the specified entity. So "Entity Reuse" would
   be more descriptive. Possible terms based on that might be
   "entity reuse reference", "entity reuse link", "entity reuse
   specification", or "entity reuser".

   Given the existence of "entity reusers", it becomes clear that
   the result of a drag and drop gesture should be the production
   of either an entity-reuse-link or a reference-link to the
   original document segment. Doing that lets you recategorize
   information without changing the original. A "move" operation
   thus consists of a) Linking to the original from a new location
   and b) "Deleting" the original from the new version of the
   document. (It still exists in the old version.)

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:

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