Memorandum
Date: Sat, 19 Feb 2000 16:21:35 -0800
From: Eric Armstrong
To: "unrev-II@onelist.com"
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:
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.
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
displayed.
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.
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
doc"
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
otherwise.
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.]
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.)
Subject:
DKR/OHS: 5 Authoring Requirements
Five fundamental operations the system must have...
Sincerely,
Eric Armstrong
eric.armstrong@eng.sun.com>