My memory is overgrown with groves...

Subject: My memory is overgrown with groves...
From: Brandon Ibach <bibach@xxxxxxxxxxxxxx>
Date: Thu, 22 Jul 1999 23:25:23 -0500
   Just for fun on a Thursday night, I was meandering through the
wonderful documentation of the SGML Property Set at hytime.org, and a
thought occurred to me.  I imagined what a monstrosity would result
from coding a grove builder (like spgrove) that actually supported
*all* of the modules (of which there are 26, total).  Subsequently, it
occurred to me, as I browsed the list of classes and properties
supported by each module, that there would be a *ton* of redundancy,
as (I figure) many of these nodes could easily be calculated from
more basic node types and properties.
   The point to which this all leads ties in nicely with our recent
discussion about memory requirements for groves.  Not knowing the
internals that well, I don't know if what I'm about to say will be
totally legit, but what if we created a version of spgrove that built
the grove in a more "lazy" fashion?  Specifically, it could build data
structures in memory as needed to provide structural information to
the SDQL process, but it could store most of the document in a
less-structured, very compact form which it could access very quickly
to build the more structured stuff needed to respond to queries.  This
more structured information could be built and destroyed as needed,
and would stay around for a very short time, as the cost of these
operations would be small.
   Furthermore, the operations that would build these structures from
the more compact storage would probably fall into a number of broad
categories.  In other words, there would be many different properties
(which are, after all, the meat of any query process) which would all
be built into structured form in basically the same way, so the grove
builder could be equipped with a number of these "generic" operations,
and the actual information about the different properties and how they
are extracted from the compact document representation would be static
data fed into the process, thus making the grove building process
almost totally data-driven.  This could make the construction of new
modules easier, as most of them would just reuse the generic ops.
   What do you think, OpenJade gurus?  On that note, is Kathleen (sp?)
on the list these days?  I'd think, given her recent implementation of
the prlgabs1 module, that she'd have a pretty good knowledge of the
internals of spgrove.

-Brandon :)


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread