This is a great insight. In fact, I'm cross-postiing this response to open
the discussion to others who are not on OHS-DEV.
I have been a great fan of groves. I watched a demo of GroveMinder, in
which a single web page was created from a Word document and an Excel
spreadsheet, all through the grove engine. What they have is a basic engine
coupled to plug in adaptors, each of which is coded specifically for a given
document type. GroveMinder lets you write your own adaptors in Python and
just plug them in. (BTW: I have not been eager to climb the SGML mountain,
which is why I am enthused by the possibility of doing groves and HyTime in
I mentioned this before, but at this URL, http://www.inxar.org/ , there is a
discussion and javadoc for what the author told me is a different way of
thinking about groves. His metaphor is that of lilly pads in a pond.
A distributed grove engine, of which GroveMinder just might be an instance,
coupled with distributed document management tools, if not a killer app,
will certainly be an OHS core technology. I think OHS core technology will,
itself, be a killer app.
----- Original Message -----
From: Lee Iverson <firstname.lastname@example.org>
Sent: Wednesday, February 14, 2001 8:01 AM
Subject: Re: DKRs without the "K"
> In message <Pine.LNX.email@example.com>,
> ric Kim writes:
> >Groves are directed graphs of nodes, so the data structures you propose
> >above qualify as an implementation of a grove. A property set describes
> >how the grove is constructed and what it consists of. If you want a
> >DOM-like data model for manipulating a document, you create a property
> >that defines element nodes, attribute nodes, etc. If you want a data
> >model like the one described above, you create a property set that
> >text nodes and structure nodes and data nodes.
> >I don't think groves conflict at all with what you're proposing. In
> >I think we're essentially thinking about the same picture (you can
> >correct me if I'm being presumptuous), although I'm not sure how you
> >specify the data models with DTDs. Basically, you're proposing a grove
> >constructor which has a property set parser. In order to construct a
> >grove, you need a plug-in for that document type that consists of a
> >document parser and a property set. The document parser creates a parse
> >tree, then the grove constructor takes that tree and the property set to
> >construct the grove.
> After reading a few of the grove introductions, I'm way psyched. That is
> exactly the conclusion I've come to. What I'm designing is a distributed
> grove engine. I need to understand more about the granularity, but the
> of having a few basic building blocks for all structured document types
> a means of manipulating them in a distributed environment is going to be
> a real killer app.
> >I think the twist that you've thrown in (which you first introduced when
> >you suggested the DDOM many moons ago) is that your grove implementation
> >is designed to work in a distributed environment, with features like
> >version control. That's cool stuff.
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 firstname.lastname@example.org
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:01 PDT