cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce G. Robertson" <brobert...@mta.ca>
Subject Re: DOM to DOM processing options
Date Thu, 28 Sep 2000 02:14:55 GMT
On Thu, Sep 28, 2000 at 12:13:36AM +0100, Robin Green wrote:

> "Bruce G. Robertson" <brobertson@mta.ca> wrote:
> >2. Make a Cocoon 1.* Processor, which would just be a wrapper around my
> >code that does DOM to DOM. When I switch to Cocoon 2.*, I'll have to
> >make this into a SAX-friendly thingy, right?
> 
> DOM2SAX and SAX2DOM adapters will be provided, so we're told - but it's much 
> more efficient (from a Cocoon 2 point of view) to generate SAX in the first 
> place (no expensive object creation!), and only generate DOM objects from 
> SAX if necessary (by implementing org.apache.cocoon.framework.XObject), i.e. 
> only if running under Cocoon 1. The impact on Cocoon 1 of SAX->DOM as 
> opposed to direct DOM building should be negligible.
> 
> But obviously this requires significant recoding on your part! :(

Well, not necessarily on the input side of things, and as for the DOM 
Document output, that comes from the java svg generator, so I can't 
imagine there's anything I can do to make that process less expensive.

However, my prime goal is to demonstrate these technologies and test out
XML Schemata relating to my discipline, not mean/lean production like
most of you. 

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?

Many thanks,
-- 
Bruce Robertson, Dept. of Classics, Mount Allison University
http://www.mta.ca/faculty/humanities/classics/Robertson/ 

Mime
View raw message