[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Streaming XML (WAS: More on taming SAX (was Re: [xml-d
* Uche Ogbuji <uche.ogbuji@f...> [2004-12-30 23:00]: > On Thu, 2004-12-30 at 19:50 -0800, Bob Foster wrote: > > This is unproductive. > > Indeed. I was pretty much done with the thread. > > > Miles makes the point that parallel > > ContentHandlers wouldn't be SAX as we know it. You seem to be saying you > > could design a parallel version of SAX that could work, by some > > definition. Since document processing is unlikely to "work" if events > > occur in an arbitrary order on arbitrary threads, I assume you mean > > there would be a mechanism to control which elements could be processed > > in parallel. For the result to be called XML, there would also have to > > be sufficient locking to ensure that PIs arrive in document order wrt > > other events, etc. It's an interesting idea. > > And yet not an idea I'm likely to bother with in actual practice in the > forseeable future, so I really should have signed off this sideshow a > few messages ago. I'll amend that now. Hi. OP, here. It was all very illuminating. It tells me that SAX, as an API, is missing support for parallel processing. Parellel porcessing is possible in SAX, or rather, it is possible with ContentHandler implementations that were co-operative and synchorized, but then you're forgetting an interface to specify ContentHandlers, and a bunch of other whatnot. As such, parallel SAX, doesn't make much sense, but parallel processing of streaming XML is not, for some reason that I could not see, impossible. Thanks, Miles and Uche. -- Alan Gutierrez - alan@e...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|