Lists Home |
Date Index |
- From: Paul Tchistopolskii <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 26 Dec 2000 15:17:59 -0800
----- Original Message -----
From: Simon St.Laurent <email@example.com>
> 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.
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.