xml-dev - Re: XML syntax for XPath?

[Paul Tchistopolskii <paul@qub.com>]

----- Original Message ----- 
From: Simon St.Laurent <simonstl@simonstl.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. 

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.