[unrev-II] [Fwd: Possible Additional Requirements] (fwd)

From: Eugene Eric Kim (eekim@eekim.com)
Date: Tue Jun 27 2000 - 09:24:50 PDT

  • Next message: Eugene Eric Kim: "[unrev-II] [Fwd: **Servlets for email**] (fwd)"

    ---------- Forwarded message ----------
    Date: Mon, 26 Jun 2000 22:06:12 -0700
    From: Eric Armstrong <eric.armstrong@eng.sun.com>
    To: Eugene Kim <eekim@eekim.com>
    Subject: [Fwd: Possible Additional Requirements]

    The second one.

    -------- Original Message --------
    Subject: Possible Additional Requirements
    Date: Mon, 26 Jun 2000 21:05:50 -0700
    From: Eric Armstrong <eric.armstrong@eng.sun.com>
    To: unrev2 <unrev-II@onelist.com>

    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
        --the ability to freeze a document, so no more
          comments can be added.
        --the ability to add comments to a document,
          but not edit it (perhaps controlled by a
          reviewer list)
        --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:

      Originator Text Category
      --------- --------------------- ------------
       Author: text with typo in it [Document]

       Author: text with typo in it [Document]
          Editor: there's a typo there [Correction]

       Author: text with typo fixed [Document]
          Editor: there's a typo there [Correction]
             Author: fixed it [Response]
       Author: text with typo in it [Document]

       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).

       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.

      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.

    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).

    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

    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.

    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 2b29 : Tue Jun 27 2000 - 11:32:56 PDT