Re: [ba-ohs-talk] Concept: Typed Versioning
> 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
--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)
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
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)