Re: DSSSL side effect-freeness

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

At 06:39 PM 1/28/98 +0100, Pierre Mai wrote:

>    FAC> distributed, though -- and I can't imagine distributed groves
>    FAC> being a typical case anyway.
>
>Well, if we look at the corporate world, where large technical
>document repositories are being maintained and deployed as IETMs for
>example, I would rather think that distributed groves might be heavily
>used...

In fact, there's no other way to manage very large documents, at least not
that I can see.  If you look at tools like Chrystal's Astoria or Texcel's
Information Manager, they are essentially grove managers.  As soon as these
tools let you connect two physically separate repositories to form a
single, logical, grove, you've got distributed groves.  The GroveMinder
system being developed by TechnoTeacher will provide very complete, very
robust grove management layer that will include support for distributed
groves (in the sense that a single grove or hypergrove could be constructed
from data stored in a variety of repositories).  

[Note that neither Astoria nor Texcel (nor any "grove manager" product of
which I'm aware) is a true grove manager for two reasons: 1. they got
entities wrong, which is fatal, 2. they don't necessarily reflect the SGML
property set. Both of these failings should be easy to fix, should either
company decide to do so. These critiques are not news to them, trust me.]

The issue of distributed groves is ultimately one of processing
optimization: if you're going to process huge documents in a reasonable
amount of time, it's probably unreasonable to construct the hypergrove anew
every time you want to process something. Thus, you construct the bits of
the grove whenever its source data changes so that the total hypergrove is
immediately available when you need it.  Of course, this is at the cost of
large amounts of disk storage, but DASD is cheap, right? (Note that I'm
assuming that large volumes of data will not be stored as single SGML
documents, which is both foolish and impossible. The processing of multiple
documents (and non-SGML component objects) always results in a hypergrove.)

Also, if you assume that the size of documents reflects the tasks they
support and not available computing resources, then document size should
not increase dramatically over time but computing power will increase
exponentially (given that Moore's law holds).  That means that at some
point, computers will be so fast that the thought of regenerating the
hypergrove for a multi-gigabyte body of data will not frighten the IS
folks. In other words, if it takes X pages to describe a ship today, it
will probably take X pages in 10 years, but computers will be many times
faster.

Note also that it's only a problem at very large scales, like preparing the
documents for ships or planes, which combine high data volumes with rapid
refresh cycles. At smaller scales, systems are more than fast enough to
brute force their way through most problems.

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of 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