DOM is just one possible representation. There is no constraint on the JAXP interface (javax.xml.xpath.*) that the representation of the document needs to be a DOM or that when you pass in an InputSource to this API that it actually a builds a DOM under the covers, though that's likely what the implementation in the JDK does. There may be alternative implementations out there which perform better (faster / lower memory requirements) but that's a question best suited for another mailing list as this doesn't really have anything to do with Xerces.
Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Ramon F Herrera <ra...@patriot.net> wrote on 10/08/2010 11:01:49 AM: > Newbie alert... > > After a LOT of searching around (programming languages, libraries, > toolkits, etc.) I have concluded that XPath is the best approach for my > application. I found an implementation and my app is running fine. The > only problem is that the app is rather slow, and I foresee the need for > speed. > > See my imports below. The reason for the sluggish performance is that my > XPath is based on DOM, and for every element retrieved the whole tree > must be re-evaluated. Needless to say, that is very inefficient. > > Is there any XPath implementation based on SAX out there? Frankly, I > don't even know where to start. Pointers would be very much appreciated. > > TIA, > > -Ramon > > ps: I only do retrieves, my XML files are large and read-only. > > ------------------------------ > > import javax.xml.xpath.XPath; > import javax.xml.xpath.XPathConstants; > import javax.xml.xpath.XPathExpressionException; > import javax.xml.xpath.XPathFactory; > > import org.w3c.dom.Node; > import org.w3c.dom.NodeList; > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org
