cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <gree...@hotmail.com>
Subject Re: Cocoon 2.0: proposed battleplan
Date Sat, 15 Apr 2000 13:38:55 GMT
Donald Ball <balld@webslingerZ.com> wrote:
>On Fri, 14 Apr 2000, Pier P. Fumagalli wrote:
>
> > Because, doing it before, or doing it after, it's the same thing....
> > We won't loose that much performance on that, and it surely eases the
> > whole architecture (having only one way to pass XML from one place to
> > another!)
>
>But doing it before, the XML parser gets to do it internally. Doing it
>after, we have to construct the DOM from SAX events. I reckon the former
>would be faster... should I do some tests?

Um, how could it be?? This is how an XML parser works, surely:

Either like this:

        **********
t.xml ->* PARSER *-> SAX
        **********

or like this:

         ***DOM PARSER****
t.xml -> * PARSER -> SAX * -> DOM
         *****************

(Even if it is not standards-conformant it still has to behave in one of 
those two ways.) So all you would be doing is redrawing the boundaries of 
the parser - overall, the code would still be doing the exact same thing.

A parser HAS to build a DOM tree out of SAX events (or something equivalent 
to SAX events) - they just represent the parser saying "Encountered X", 
"Encountered Y", etc. etc. How could it be done any more efficiently? Apart 
from little things like "make all DocumentHandler methods final", it 
couldn't!

And the same is true at any stage of the pipeline, not just for the parser 
at the start.

--
Robin

Open Source Java links galore! 
http://dmoz.org/Computers/Programming/Languages/Java/Open_Source/
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Mime
View raw message