[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

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


Sandy Klausner wrote:    (01)

> So now two mechanisms need development. One to represent the dynamic linking
> and separate meta logic for determining the syntax/semantic update behavior.
> Seems that the dynamic linking mechanism should be generic, while provisions
> for user control to declare domain specific update behavior would drive the
> generic linking.    (02)

Thinking in terms of the great picture that Lee gave me at dinner one night,
a link to a node (in Nodal) always points to the top of a chain. Below that
the chain is the progression of revisions, where the top most revision in the
chain is the most recent.    (03)

I'm pretty sure I agree with Eugene that link typing must be an integral part
of the system. How that gets added to Nodal, I'm not sure, but let's say it
is.    (04)

I see link types as something the user controls. (I think Eugene and I have
different concepts here. What I'm presenting now is my view.) 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.    (05)

     Note:
     It's the syntax/semantic difference once again, although this time in
     a new setting. The link type sets the *semantics* for the link. It
     tells whether material is supposed to be inlined, or whether an
     underlined title should be displayed, for example. The user settings
     determine the *syntax*. (Should titles be displayed in blue or red.
     Should they be underlined.)    (06)

Returning now to the original syntax/semantics difference, lets assume
that the versioning system is capaple of determining whether a node
change is syntactic, or whether it represents a semantic change.    (07)

If the change is syntactic, the new version becomes the head of the chain,
and old links point to that version. If the change is semantic, a branch is
created. The link then continues to point to the head of the old chain,
with some visual indicator that a branch has occurred, and the link is
pointing to an older version.    (08)

Perhaps the document author even gets a notification that a semantic
change occurred. That could be cool. Sort of an automated response
to a node in my document informing that one my dependencies has
been revv'd. (Or maybe it would be awful. Dunno.)    (09)

The document author can then choose to update the link or leave it
pointing to the old version. In either case, the document returns to
displaying a single link.    (010)

Until the document author does so, however, a person reading the
document sees both the link and the "updated version exists"
indicator. They get an opportunity to inspect both versions, until
the author(s) have made up their mind which they prefer.    (011)

Finally, in matters of syntactic eloquence, an author needs the ability
to say, "link to that version, come hell or high water, no matter what
kind of change occurs". That way, when some particulary pithy phrase
is quoted, there is no danger of it degrading to something less eloquent
in the future.    (012)