Re: We need an XPath API

[Charles Reitzel <creitzel@mediaone.net>]

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).
>