RE: Future of DSSSL: What about PDF?

Subject: RE: Future of DSSSL: What about PDF?
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sat, 6 Mar 1999 17:20:10 -0500
Hi Brandon

<YourComment>
   Beyond all this, however, I'd like to find out what you all think
of an alternative to the closely coupled formatter and engine.  I
recall that we had a discussion along these lines some months ago, and
one of the alternatives was to create higher level FOs that could
"encapsulate" some of the more complicated formatting tasks which
might otherwise require such a coupling with the formatter.
   I see two main advantages to this.  First, we avoid the complexity
of coupling the formatter to the engine.  Second, and this is one that
the coupling solution can't even touch, is the fact that it allows for
a complete separation of the styling and rendering processes.  As an
example, what if you're dealing with a client/server situation where
you've got the DSSSL engine doing the styling on the server, and an
advanced rendering engine on the client, and there's no way for the
two to communicate beyond a simple transfer protocol (such as HTTP).
This could well be the case for a client behind a firewall.  Another
possibility would be a situation where the DSSSL processing is done in
batch mode, but the rendering is done on demand, possibly including
dynamic information, such as the current date, each time.
   This idea is, of course, based more on general design concepts than
on practical knowledge of the problems which these approaches would
need to solve, so I'm certainly wide open to any comments on the
feasibility of this idea.
</YourComment>

<Reply>
You would be surprised of how well a dsssl engine can transform a SGML or
XML document into HTML for browsers delivery. We are currently testing a
SGML/XML server running under IIS 4.x (we are porting it to Apache too) and
the result is surprising, without optimization we get faster results or
similar results to XSL based scripts with Microsoft XSL engine. With
optimization, it could be faster. For an average loaded server, the result
is reasonnable. For heavy loaded servers we plan to use the groveobjects
(mentioned in the previous post) with permanent storage. So, you store you
SGML/XML document on the server. It is parsed on included on a grove object
hierarchy. Then, the dsssl engine process directly on this grove instead of
reparsing the document each time. The result is a HTML document sent to the
browser. Early testing match ASP processing. So the trick on the server is
to have the document pre-parsed and stored in a "permanent" grove. The dsssl
engine intereact with this grove. In that case, we don't use a secondary
formatting objects grove but instead send directly the HTML+CSS FOs.
A good point on this architecture is that both a XSL and a DSSSL engines
could make processing on the same document grove.
</Reply>

Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


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


Current Thread