Re: [ba-ohs-talk] Concept: Typed Versioning

[Eric Armstrong <eric.armstrong@sun.com>]

> On Thu, 21 Mar 2002, Eric Armstrong wrote:
>
> > I see link types as something the user controls...The user
> > sets a link type as one of (for example) response, counter-argument,
> > inline inclusion, simple reference, like that. The way the system displays
> > linked material is primarily determined by those types, and also controlled
> > by the user.
>
> On Fri, 22 Mar 2002, Eric Armstrong wrote:
>
> > In my view, that is correct. My impression of  them is something that
> > would want to be built in at a higher level, in the engine that uses Nodal.
>
> Eugene Eric Kim wrote:
>
> That should certainly be doable.  My question is, why is it desirable to
> build it at a higher level?    (01)

Hmm. I see multiple factors in the design decision:
  1. Can we completely enumerate the class of link types, and be
      certain there is no need for some application to create a new one
      that others don't need?
         --if so, it would be nice if they were built in
         --if not, it would be better if they were added by the application    (02)

        [I lean towards the former.]    (03)

  2. Can we be reasonably certain that the complete set of links
      is required by all applications?
         --if so, it again makes sense to have it as part of the data engine
            spec
         --if not, applications could smaller, lighter engines without them    (04)

         [No clear choice for me, here.]    (05)

  3. Can the data engine provide profitable manipulations for those
      link types, or do their semantics properly exist at a higher level?
         --if so, it makes sense to implement them as part of the engine
         --if not, it makes sense to implement them higher up    (06)

      Here, I lean towards the latter. It would be hecka convenient
      if the engine included links, but there may be no reasonable
      semantics one can construct. Take for example the concept of
      an "inclusion" link. Nodal is a node-engine, it doesn't know
      about documents. So there are no meaningful semantics that
      Nodal could perform.    (07)

       Note:
       Even as I speak, I see a major exception. It's the inline
       vs structure distinction, again. An inclusion link consisting
       solely of text could be processed inline, within the context
       of a node. (Think of a product name in a document.) But
       an inclusion link that consisted of a structure (even if it were
       only a node) would only have useful semantics at the document
       level.    (08)

   4. Onions are a good design.
       If it links were wrapped around the node layer like an onion,
       and it turns out that it made sense to include them in the data
       engine, then the data engine could be redefined to include that
       layer. Assuming that it is equally easy to build them either way,
       (an assumption which may not be true), then it makes sense to
       prefer the method that gives the most design flexibility.    (09)

    5. Modular reuse may suggest it.
        If, when I'm thinking about how I want to implement and make
        use of link types, I find that I can reuse mechanisms that are
        planned for the data engine, then it makes sense to build the data
        engine first and tack them on later.    (010)

Basically, that's my view on things at the moment. Specific information
encountered during development or use could easily change that
opinion, but I've tried to identify the assumptions that make me lean the
way I do.    (011)