Re: Comments on NODAL paper, 14 June 2001 version

[Lee Iverson <leei@ai.sri.com>]

In message <Pine.LNX.4.33.0108091119420.1197-100000@hugh.burdenslanding.org>, E
ugene Eric Kim writes:
>On Thu, 9 Aug 2001, Lee Iverson wrote:
>
>> 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.
>
>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.    (01)

Certainly true.    (02)

>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.
>
>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.
>
>Suppose you want to transclude the common information in all of your
>source code files.  How do you do this?    (03)

Well, transclusion is just the act of creating a node reference.  If
we're talking about a string of text to be included in a comment
block, then that one is easy to do.    (04)

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

The data model is defined such that every *collection* (and NODAL
supports three types of collections) is a node.  So, a comment block
in the Java program data model could be defined as a sequence of
strings.  Reusing such a sequence (or the comment block itself) would
be pretty simple.  I guess part of the issue is how do you design data
models to promote component reuse? I do think that there *is* a
potential issue as to how easy it might be to build data models that
are difficult to tease apart.     (06)

>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?    (07)

Another possibility for handling this (and it came up when I discussed
this with Doug on Tuesday) would be the liberal use of "path
functions" (a la XPath).  It would almost certainly be possible to
define functions (pluggable and well-defined) to access the "third
paragraph" and "second sentence" of a text block.  That way we
wouldn't have to worry about data model mapping (yet at least).    (08)

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307    (09)