-0.7
I would only state that this will obviously make a difference in
performance in large documents, since every trip out of the parser now goes
through twice as many calls along the way, with both sets being
indirections via a pointer. For that reason I personally wouldn't be in
favor of getting rid of a DOM parser hard coded to the internal event APIs.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
Paul Prescod <[EMAIL PROTECTED]> on 02/02/2000 12:35:13 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: SAX2 and DOM...
Pierpaolo Fumagalli wrote:
>
> Since with SAX 2.0 we'll be able to fully build a DOM, what about
> "dropping" the current DOMParser and SAXParser, keeping just one of them
> (the SAX one) and relying on a SAX-to-DOM to get the documents?
I strongly support this idea. It will be useful to be able to build DOMs
from the results of filters and XSLT transforms. This is doable if the
DOM Builder is just another SAX event consumer.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"Ivory towers are no longer in order. We need ivory
networks. Today, sitting quietly and thinking is the
world�s greatest generator of wealth and prosperity."
- http://www.bespoke.org/viridian/print.asp?t=140
