Re: [Fwd: Uses of DSSSL]

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

At 07:34 AM 6/28/97 -0400, David Megginson wrote:

>I prefer Jade to Perl for most of my work, but there are still three
>compelling reasons to use Perl instead of the current version of Jade:
>
>1. To handle SGML documents larger than about 1/3 of available memory
>   (when you're processing the ESIS with Perl, you can construct a
>   script which uses memory based only on the depth of the element
>   tree, not on its total node count).

Depends on how much of the tree you need.  Doing most HyTime processing
requires building lots of tables that can get quite large, approaching, if
not exceeding, the size needed to keep the doc grove in memory.  Jade is
fast enough that the optimization of table building is not needed (at least
I haven't reached that point yet).

And as James said (as as Belize has or will demonstrate), on-disk groves
shouldn't be that slow.

>2. To add information from other sources (database fetches, Internet
>   connections, other programs on the operating system etc.) during
>   the transform.

DSSSL (and Jade) should be able to provide this through the facilities
inherent in the grove abstraction.  In essessence, when you refer to a data
entity you are really referring to the grove constructed from that data
entity.  SGML presumes that every data notation has, at a minimum, a
default property set used for groves in that notation.  Once you have a
grove, you can do anything you want to with it, including apply DSSSL
processing and HyTime location addressing.

The logic underlying the presumption of default grove plans is:

1. If a data notation is structured sufficiently to allow *some* program to
interpret it THEN
2. There must be some documentation of that structure (either in prose or
program code) THEREFORE
3. It must be possible to define a property set that expresses those
structures
THEREFORE
4. It must be possible to write software that provides a grove view of the
data using that property set

>From an implementation standpoint this will typically mean that to
integrate the processor for some data notation (e.g., a database, graphic
format, non-SGML document processor) you simply need to provide a
grove-based API for that format that tools like Jade and GroveMinder can
talk to.  This is the same thing you do with Omnimark or Balize when you
use their API integration features to connect to a database--the only
difference is that for DSSSL and HyTime the object schema is formally
defined as a property set. [And having defined the object schema as a
property set general grove processors like GroveMinder {soon from
TechnoTeacher} can generate the starting point for the API code from the
property set, needing only to have the methods filled in.]

Given that Jade has a grove API, it ought to be possible to create a
grove-based integration with anything such that you can use functions like
"node-property" to access information from databases, for example.  In
fact, if you use the property set to define your database schema, you have
a produce-independent definition of your schema that protects your data's
semantics from the details of particular database implementations.  This
could be very advantageous.

In addition to the presumed default grove plan for data entities, HyTime
provides mechanisms by you can explicitly associate grove constructors and
grove plans with data entities.  In other words, we've generalized the
grove mechanism to all data, not just SGML, and given you a syntax for
using that generalization within documents, not just from program command
lines and processing scripts.

>3. To do complex string manipulation based on regular expressions.

Gotta give you that, although a DSSSL engine *could* be optimized to do
string manipulation and pattern matching efficiently.  Whether or not it's
a good idea to do so, I'll leave to the implementors to decide.

Cheers,

E.
--
<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