RE: Architectural Forms, separation of formatting and loose-leaf management

["W. Eliot Kimber" <eliot@xxxxxxxxxx>]

At 02:51 PM 5/7/98 +0900, Frank A. Christoph wrote:
>>Much of the benefit of
>>groves is simply that the abstract interface to them is standardized.
>>This means that both grove-generic and property-set-specific
>>applications can be written such that they are insulated from the
>>actual storage implementation of the data they access.
>
>Isn't this the _only_ benefit?  As far as I can see, the only significant
>difference between a grove and a(n abstract syntax) tree is that groves have
>a mechanism for representing references.  The grove API itself can be
>defined for any AST.

More or less.  The primary purpose for creating groves was to provide a
standardized abstraction for parsed data that the DSSSL and HyTime
standards could then be defined in terms of. It didn't really matter *what*
that standardization was, just that there was one.  However, because it had
to be done, we (mostly James) took the opportunity to optimize and enhance
the abstraction for the convenience of SGML processing, thus things like
the concept of "content properties", named node lists, and principal tree
roots, which make doing SGML processing easier by encapsulating some common
operations.  

There's nothing in groves that isn't an application of normal abstract data
representation techniques, so in that sense there's no magic to groves
beyond their being a standard with some (we think) useful properties over
and above generic node graphs.

I'm finding, for example, that it's very easy to implement grove
constructors given a general grove implementation and property sets because
90% of the data representation design is done--it becomes a matter of
interpreting the property set and figuring out how to set the properties
from the source data. I don't have to invent the data structures in my
program. [Of course, for any given data type, the internal representation
is not optimized, but that's the trade off--ease of implementation at the
cost of optimization, which can always be added later through specialized
implementations of my grove node object class.]

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>


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