These notes really need to be discussed in the
Wiki system. Maybe they each need their own
section? They represent possible additional
requirements for the system, based on discussion
at the design meetings, thoughts that came out
of writing up the data structures document, and
discussions held on this list.
Document Access Controls
------------------------
Frozen
--the ability to freeze a document, so no more
comments can be added.
Commentable
--the ability to add comments to a document,
but not edit it (perhaps controlled by a
reviewer list)
Editable
--the ability to make changes (perhaps controlled
by an author list)
Editing Interactions
--------------------
"Suggestion/Correction" nodes & thier replies are
automatically removed when a document or subtree is
versioned, like this:
Action
Originator Text Category
--------- --------------------- ------------
write:
Author: text with typo in it [Document]
review:
Author: text with typo in it [Document]
Editor: there's a typo there [Correction]
revise:
Author: text with typo fixed [Document]
Editor: there's a typo there [Correction]
Author: fixed it [Response]
Author: text with typo in it [Document]
version:
Author: text with typo fixed [Document]
That allows editors and reviewers to sign off on the
changes before the version is "committed".
Exposed Anchors
---------------
In HTML, <i>anchors</i> are the targets that links can
point to. ("Targets" would be a better term, in fact.)
The problem with HTML is that anchors are not exposed.
It is easy to refer to someone else's document, but very
hard to refer to nodes inside it. (It's possible, if you
inspect the source file closely, but very difficult.)
Augment solved that problem by putting small purple numbers
at the end of each paragraph. Those numbers could be dragged
and dropped to create links. That functionality is fundamental
for intelligent reuse of information in the system.
Logical Styles
--------------
This requirement surfaced as a result of working through the
data structures. Text styles using "inline tags" like bold
and italics are easily accomodated in the system. But what
about different paragraph styles, like bullets and lists?
In the the data structures document, it is argued that "style"
actually has two components -- a display component (what font
to use, what bullet to use) and a logical compoent (ordered
or unordered list, plain paragraph).
Note:
The data structures document also called for the ability
to add new inline tags by setting up an equivalence with
a display-style. So if <i> renders emphasis using italics,
then <def>=<i> would define a "definition" tag (or
<gls>=<i> for a glossary tag). That tag would a link to
the glossary list (adding the term, if necessary). Overtime,
that term would acquire pointers to every definition given
for it in the system.
In a system where reuse is a given, it makes particular sense
to separate logical style from display style. An ordered list
might originate under a paragraph, and have the numbering 1, 2,
etc. But someone else might reuse that list under a numbered
list of their own, which would cause the numbering to change
to a, b, c, etc.
However, in each case, the fact that the list is ordered
provides information. The ordering indicates a sequence of
operations. An unordered list, on the other hand, indicates
an enumeration of possiblities, but one in which sequence is
not important.
Such "logical styles" make for reasonable inclusions in a text
processing system. It is noteworthy that HTML started with
such styles -- and very little else.
Note:
The existence of logical styles gives the interative
display a chance to do the appropriate formatting.
Equivalences like <def>=<i> would be seen as default
suggestions that could be overridden by the user. In
addition, various "smart formatting" heuristics can be
used to format lists. The StreamLine outliner used a
simple heuristic: If a list entry had children or
multiple lines, then double space after it, otherwise,
single space after it. That heuristic tended to keep
lists of short items together:
* like this
* and this
* and this
It also tended to produce desirable extra space around
long items or items with comemnts:
* an item
--with a comment
* A long ...
...multi-line item
* Another item
An improvement on that would inspect the list and treat
all items uniformly. (If any one item is double spaced,
then double space them all for uniformity.) All such
capabilities are in the domain of the display/print
application. However, they are made possible by the
existence of logical styles.
Tables
------
The first two things added to HTML were forms and tables.
Fortunately, the system being defined here has very
little need for forms. But tables are another matter.
Tables are highly useful formats for displaying information
that are rather tricky to implement.
In the data structures document it was argued that the
existence of categories and links (&/or relations) provides
a mechanism for defining tables. If each column is a category,
and each item in the first row is a "selector", then the
remaining columns are filled with items that are linked
(&/or related to) items in the selector column.
That mechanism provides a seriously cool way to create
tables dynamically and see how things are related -- all of
which occurs in the display app. Having created that view,
however, it would nice to save either a static or dynamic
copy of it. Saving a dynamic copy would entail listing
the categories, and possibly the selection criteria for items
in the selector row, and maybe selection criteria for
linked (related) items in other rows. Including that
specification in a document would then signal the display
to create the table.
Dynamic copies are probably the easiest to develop, and they
are still darn hard. The data structure needs a mechanism
for saving "construction instructions", and the display
mechanism needs the ability to deal with tables. (Fortunately,
using an HTML-based display mechanism means that the ability
is already built-in.)
But saving static copies is harder. It means saving
an "instant in time" snapshot of the value set produced by
the selection criteria, and the current versions of all
related nodes. The table would have to consist of
<def>hard links</def> (links that go directly to specific
versions, as opposed to <def>soft links</def> that point
to the latest version of a node).
View-Presentable
----------------
This requirement comes from an analysis of the NLS video. In
retrospect it seems almost obvious -- but that is the way
with brilliant ideas. (I've been cogitating on this subject
for between 6 months and 15 years, depending on how you count,
and the idea never occurred to *me*.)
The idea is that, in any view-controllable system (an outliner,
NLS, Augment, etc.) a link must be able to specify not only a
destination, but the view parametersto use when displaying that
data. In essence, then, you create a view, and then "present" it
to
Adding view-control information to the link also solves the
table problem nicely. A table *is* a view of related categories,
and the "view control" says "display the matrix inline". (NLS
only had click-to-traverse links. But adding the "inline"
capability provides a really powerful mechanism for constructing
new documents from nodes that already exist in the system.)
Back Links
----------
I keep leaving this out of my design space -- the one in my
head, as well as the one on paper -- but it's important.
Back links let a node identify every other node that points
to it. So, if I add put a comment in the system that links
to a node in your document, you have the ability to retreive
all of the comments made on your document, and display them
in context as you edit.
Character Selectable (??)
-------------------------
Pat's brother (sorry, forgot his name) suggested that,
in principle, it seemed reasonable to have the ability to
address words, and even characters, as well as nodes.
Although we don't know what to do with character addressing,
exactly, he suggested that not having that ability would
impose an arbitrary limitation.
I, personally, am wary of including character-addressing.
It seems to me that it introduces complexity without gaining
a lot of useful functionality. There are several possible
ways to sell the concept, however:
a. Demonstrate a design that makes it simple.
If it's free, why not? One way to do that might be
take on a "character offset" to a node pointer.
But I forsee a lot of compute time spent keeping the
durn things up to date, if they exist. A node-pointer
seems like a reasonable compromise, to me. No matter
where it moves to in an outline, no matter how much it
changes, the pointer is unaffected. But maybe there is
a better design.
b. Show that it is needed.
An unimpeachable use case settles all arguments.
c. Expand it to a "selection pointer".
That last item really peaks my interest. Although individual
characters would not, in principle, be addressable. It seems
desirable for any given *selection* to be addressable. That
allows for quotations from the original source, without having
to include the entire node. The same mechanism then produces
sentence, phrase, word, and character addressing, when needed.
I'm not at all sure how it work or how much complexity it
would introduce, but it seems desirable.
------------------------------------------------------------------------
Want insight into hot IPOs, investing strategies and stocks to watch?
Red Herring FREE newsletters provide strategic analysis for investors.
http://click.egroups.com/1/5176/5/_/444287/_/962130319/
------------------------------------------------------------------------
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 2b29 : Tue Jun 27 2000 - 11:33:53 PDT