[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML syntax for XPath?
----- Original Message ----- From: Simon St.Laurent <simonstl@s...> > At 01:47 PM 12/26/00 -0800, Paul Tchistopolskii wrote: > >I'm constantly asking for particular example, but I have no luck yet. > >I'll be very glad to see a particular usecase that requires XML-ization > >of Xpath. > > For me, it's mostly a matter of being able to use familiar tools on > structured data rather than having to go back to text processing. > XPath, CSS selectors, the XHTML style attribute, and a bunch of other types > involve multiple layers of information packed into a short string. I don't > need to see these as XML, but since I'm used to manipulating XML > information on a regular basis using XML tools, and encounter these things > in an XML context, it just seems like an easier way to deal with it. > > (And no, I don't actually plan to use XSLT on it - just SAX filters.) This is very understandable. In fact I was thinking the same way when I've started writing Xpath parser. I thought : "I'l get everything as a stream of SAX events and life will be good". Then I asked myself - how I'l gonna *use* that stream of SAX events. So OK - I'l write a SAXParser that will receive an Xpath string and that SAXParser will return me a stream of SAX events - what I'l do with that stream ( if not feeding XSL with that stream )? I have an alternative: 1. Pass that stream to DOM builder and then get a DOM. DOM is in fact a "universal bytecode". But this bytecode is *not* good for the execution. Yes. If I compile Xpath into DOM bytecode and then I have to 'execute' that DOM bytecode - it will be terribly slow. 2. OK, so maybe I'l get a stream of SAX events and will then prepare my own bytecode? But wait - if I'm anyway going to my own bytecode, why not bulding that bytecode on the level of Xpath parser itself ? Why bother with SAX serialization? SAX is a lexer. The *real* job ( building reasonable and efficient application-specific bytecode ) starts on the level up. Some things can be done with 'universal bytecode' == DOM , but when it comes to execution of Xpath statements - this is a bottleneck and using unefficient bytecode ( DOM ) in the bottelneck looks just strange. I think DOM is Ok for many other usecases where speed is not a requirment, but I think where speed is a requirement, we'l have to use application-specifc DOM's and how this is diferent from writing application-specific bytecode - I just don't understand. Maybe it is be different, unfortunately, sofar I have not seen any DOM implementation tuned for some particular application... I guess Xalan's DOM could be the case, but ... Xalan is the slowest XSLT engine, if I recall properly. I don't think I'l serialize each pixel of some bitmap into XML file. Is this possible? - yes. Is it reasonable - I don't think so. I think with Xpath we have simliar situation. As usual - I could be missing something here. Rgds.Paul. PS. XML = SAX + DOM will kill yacc? No way, I think. There will be no need in regular expressions because everything will be marked up with the markup and 'explained by RDF? No way, I think.
|
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
|