On Tue, Mar 25, 2008 at 1:07 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote: > Dinesh Premalal wrote: > > Hi Supun, > > > > "Supun Kamburugamuva" <[EMAIL PROTECTED]> writes: > > > > > >> Hi Dinesh, > >> > >> Just for the curiosity, can we integrate expat to Axiom/C? AFAIK > >> expat is not a pull parser. It registers functions for various events > >> and calls these functions when it goes through the XML. > >> > >> I'm not sure weather expat has a pull API. > >> > > > > Yes, That is the challenge, when we implementing we might happen to > > come up with a pull API on top of the SAX. Otherwise there is no much > > work to do in this project. I'm glad that you raise this question. > > > > So we are talking about wrapping Expat SAX API to come up with a STAX > API and then wrap it for AXIOM. Now my question is, would that yield > better performance that the current version of Guththila we have? If it > does, how can we verify that? If it does not, why are we doing it? >
Yes, I agree with Samisa. We know Guththila performance compared to Libxml2. If we have a performance comparison of Libxml2 and expat we may get an idea about which one is faster. But I couldn't find a comparison of these two. Another concern is that Pull parsing (Stax) and Push parsing are opposite of each other. In SAX, parsing is controlled by the parser and model builder(i.e. Stax builder) doesn't have any control over the building process. In fact there shouldn't be a model builder. So without making significant changes to the current axiom/c builders we may not be able to integrate expat. Also if we do this it will change the basic model(Stax) of the Axiom/C as well. Regards, Supun.. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
