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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
"Temporary" DSSSList archive update, DSSSList Owner | Thread | docbook style sheets or jadetex pro, Joerg Wittenberger |
Re: Named node lists, Brandon Ibach | Date | RE: sgml-parse and GC, Avi Kivity |
Month |