cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject FW: [xml-dev] Does SAX make sense?
Date Wed, 28 May 2003 14:29:45 GMT
The following came up on xml-dev.  It's relevant to the discussions we've
had in the past on SAX parsing alternatives (and somewhat academically
interesting as well :-)

In particular, note the performance comparisons with Xalan...

Peter Hunsberger

-----Original Message-----
From: Patrick Durusau [] 
Sent: Wednesday, May 28, 2003 6:27 AM
To: zhengyu
Subject: Re: [xml-dev] Does SAX make sense?


Another paper that you may find interesting is:

An Algorithm from Streaming XPath Processing with Forward and Backward 

Note that this technique has been applied to documents over 1 GB in size.


zhengyu wrote:

>I have got a weird question in mind that I would like to toss it out.
>Suppose there is a way to offer DOM type interface with SAX kind of 
>efficiency. How long would it take for the new processing model to 
>become really popular?
>----- Original Message -----
>From: "Karl Waclawek" <>
>To: <>
>Sent: Sunday, May 25, 2003 7:00 PM
>Subject: Re: [xml-dev] Does SAX make sense?
>>>There are several implementations, but I don't know of any standard 
>>>interface. I have been thinking that having a standard interface just 
>>>for passing XPath expressions to an event parser would be great. 
>>>Anyone know of a standard being worked, implementations, or 
>>>interested in starting a working group? If so, I'm in.
>>I am working on something similar, but much simpler right now. My 
>>XPaths are just straight paths, or in other words,  element types.
>>My initial plan was to build a DTD (or other schema) validator (on top 
>>of SAX) which has callback hooks for custom validation or processing. 
>>The callbacks are registered by the application based on a path - but 
>>rather a path based on the schema object model and not the document 
>>object model. Every node in the SOM corresponds to a separate set of 
>>So far I was not thinking of anything more complex, as I think this 
>>would be quite an effort.

View raw message