Re: Comments on NODAL paper, 14 June 2001 version

[Eugene Eric Kim <eekim@eekim.com>]

On Thu, 9 Aug 2001, Lee Iverson wrote:    (01)

> I do agree in the general principle.  What I have found though, is
> that unless you get into the technical aspects (at least at some
> level), a big part of your audience doesn't *get* the power of the
> approach.  It is very hard to sell a "we want to solve everybodies
> problems with computer-mediated collaboration" without a fairly
> thorough description of how you plan to do that.    (02)

I agree with this.  What I'm saying is that I think that the first part of
the white paper could serve as an overarching white paper for a lot of the
things people in this group are trying to do, not just as a white paper
for NODAL.    (03)

> Actually, it is designed for both.  There is a direct mapping from the
> data model to the navigation model to addressability (via paths and
> their translations to URIs).    (04)

Right, I wasn't as clear as I could've been.  My question was, what are
the mechanisms for alternative data models of a single document.  You
address this below.    (05)

> What we're talking about is a quite different document type and data
> model.  One way of supporting that kind of addressability would then
> be to define a bidirectional, lossless transformation from one to the
> other.  A new document (with a different MIME type) can then be entered
> into the system such that it shares content with the line-addressed
> raw text document.  If we do this right, then an edit on either side
> will be properly reflected in the other.    (06)

This answers my question... mostly. :-)    (07)

Let me try a better example than the one I presented originally.  Consider
a file containing some Java code.  Here, you could define each function as
a node, or if you want to get even more granular than that, you could
define every semantic element as a node.    (08)

Now suppose you have a comment block at the beginning of each file.  This
comment block contains mostly the same text across all files -- copyright
info, author name and e-mail, etc. -- but there is some unique content as
well -- file name, revision information, etc.    (09)

Suppose you want to transclude the common information in all of your
source code files.  How do you do this?    (010)

If a comment block represents one node, then you have to use a range
operator to specify the piece of the comment you want to use.  So the
address for the transclusion might look like: node(NID)[range].  The
problem is, now you're depending on a path-style address, which is not
guaranteed to always point at the same semantic element.  In other words,
if I add or subtract text from the comment, the range operator no longer
points to the same range of text.    (011)

The question boils down to, how granular do you make the nodes?  The data
model defines that granularity, but to support other types of actions, you
need to support alternative data models.    (012)

A bidirectional mapping from one data model to another will probably work,
but the concept scares me a bit.  Can you always guarantee an isomorphic
transformation between data models?  What are the performance implications
of doing this?    (013)

-Eugene    (014)

-- 
+=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+
|       "Writer's block is a fancy term made up by whiners so they        |
+=====  can have an excuse to drink alcohol."  --Steve Martin  ===========+    (015)