I am taking a stab at this one, even though my inbox clearly shows a bunch
of more recent replys to this thread.
If I understand what you are suggesting here, Murray, I am reminded of the
two kinds of threading in Forth: direct, and indirect. If you use direct
threading, the subroutine must remain in the same place in memory. If you
use indirect threading, the program runs a bit slower, but there is always
the opportunity to boot subroutines from somewhere else and modify a single
pointer, automatically taking care of any dependencies on the location of
that subroutine.
Right now, I am forced to do something along these lines with Nexist. It is
now time to write whatever engine will take care of occurrences (XTM talk
for raw documents). Do I design Nexist to use the Augment mechanism (a very
seductive idea), do I adapt Ted Nelson's Tumblers (also interesting), do I
just dump stuff 'out there' using absolute file addressing? or what? I do
not think the answer is obvious. That's why I brought my thoughts to this
thread in the first place.
The issues are these:
occurrences are going to be of a heterogeneous nature -- not all in the
same format
occurrences must be addressed with some mechanism that is immune to
'schema evolution' in the indexing architecture
it would be nice to have the smallest variety of tools required to solve
the problem
In the end, that's what groves are all about -- a uniform API that admits
addressability in a heterogeneous resource environment. So, do I just do
groves now? What would they look like?
If I did a grove engine, I could easily write a driver that reads Augment
documents as well as documents formatted other ways.If that is the case, is
the Augment system, or Tumblers, or whatever, the right way to go, given a
grove engine?
I do not think I possess the requisite variety of experience to formulate
reliable answers to those questions. That is why I am hacking Nexist. BTW:
the Nexist architecture would happily support lots of plug-in trials of
ideas that others might want to test.
Jack
From: Murray Altheim <altheim@eng.sun.com>
> [Was: PLink availability/feature requests]
>
> Henry van Eyken wrote:
> >
> > Jack.
> >
> > You pointed out a serious problem with the way things stand right now.
Revising
> > our HTML pages may mean attaching a different statement number to a
given
> > paragraph while keeping the URL the same. Ref. the home page, statement
no. 2G:
> > < http://www.bootstrap.org/#2G >
> >
> > The site's desired functioning and consequential architecture are still
severely
> > handicapped by the prevailence of a public networking methodology that
does not
> > yet permit the full implementation of Engelbart's individual and
collaborative
> > authoring of documents. The "funny purple numbers"*, quite aside from
their
> > immediate utility in identifying any document's elements, also serve
notice that
> > this format is but a step toward a progressive use of a superior mode of
> > authoring and publishing. In the spirit of Engelbart's lifelong mode of
working
> > ever so fruitfully, keywords here remain experiential and evolutionary.
>
> One of the things that I've been thinking about that might avoid this
> problem would be to keep a site map topic map that would act as a sort
> of online revision control system. As documents are checked in as
> replacements for older revisions, a link mapper would create a topic
> map that mapped the old links to the new. URLs to a previous version
> would be handled by a server preprocessor that would provide the updated
> link from the topic map.
>
> Just an idea, anyway. This was why I thought to put in a <meta> element
> containing plink's document generation date. I'd hate to try to build into
> my little link tool the ability to map between versions. That sounds like
> a job for a topic map, not a DOM hack.
>
> Murray
>
>
...........................................................................
> Murray Altheim, SGML/XML Grease Monkey
<mailto:altheim@eng.sun.com>
> XML Technology Center
> Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025
>
> the wood louse sits on a splinter and sings to the rising sap
> ain't it awful how winter lingers in springtimes lap -- archy
============================================================================
This message is intended only for the use of the Addressee(s) and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
the intended recipient, dissemination of this communication is prohibited.
If you have received this communication in error, please erase all copies
of the message and its attachments and notify postmaster@verticalnet.com
immediately.
============================================================================
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:04 PDT