cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Burton <ross.bur...@mail.com>
Subject Re: DOM to DOM processing options
Date Thu, 28 Sep 2000 19:44:54 GMT

> On a related note: The O'Reilly _Java and XML_ book makes a foreful case
> for the jdom parser as the best of both worlds, i.e. not costly in
> computational terms, but allowing one to walk the document, as in DOM.
> Is it ruled out as the basis of Cocoon 2 because it cannot deal with a
> stream of xml, whereas SAX can?

I know this one!  Two reasons:

1) The W3C DOM is the standard DOM for XML - JDOM is just a convienient,
more "Java-like" DOM for XML.  It is does not totally support all of the
XML spec (well, it wasn't when I last looked).  Any code written to the
W3C DOM is portable to any platform with the DOM, as the API is
platform-neutral.

2) SAX is faster.  In C2 a DOM is built only when it is needed.  A
generator spits out SAX events, which are absorbed by all transformers,
then absorbed by the serializer which reads SAX events.  If a serializer
(say, Xalan 1) wants a DOM view, it builds it first.  This leads to a
pause in the pipeline: while the DOM is being built no data can carry on
down the pipeline.  When Xalan 2 is integrated which will support an
incremental SAX XSLT transformer, as SAX events are read and templates
matched, they will be output to the serializer.  This means that
documents will be sent to the client faster, and XML documents which
will not fit into RAM as a DOM can be processed.  One of the aims of C2
was to generate a PDF file from a 200MB XML source file.

Ross Burton

Mime
View raw message