[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: We need an XPath API
Well, as it relates to an XPath API, I think there is clearly a need to support both DOM-based and SAX-based processing. Once the DOM is loaded, it is convoluted to deal with complex layere of filters. Better to mangle the DOM and pass it on down the chain. The scalability advantages of the layered SAX-filter approach would be lost and not worth the pain of you're just starting out from a DOM anyway. On Mon, 05 Mar 2001 Eric Bohlman wrote: > >3/5/01 12:37:11 PM, Christian Nentwich wrote: > >>> > 5) Work on DOM trees as well as with a SAX parser (DOM tree >>> > query support is essential in my opinion.. SAX alone is >>> > no good. What if your dom tree comes out of a database?) >>> >>> requires a well-formedness parse as the first step in processing >>> at each layer, and a stream of SAX events is the simplest, >>> lightest, and most neutral expression of that parse. In fact, as >>> a matter of local process optimization those SAX events themselves >>> may be routed through layered filters without much. >> >>To be honest, I'm a bit confused. Could you elaborate how this would >>help anyone who doesn't actually have the DOM tree represented as an XML >>file but gets it out of some data source ? I haven't been following the >>abstraction debate that much.. > >It's always possible to traverse a DOM and generate SAX events from it >(though it may not be possible to generate the sort of events a >LexicalHandler is expecting). >
|
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
|