[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML syntax for XPath?

  • From: Paul Tchistopolskii <paul@q...>
  • To: xml-dev@l...
  • Date: Tue, 26 Dec 2000 15:17:59 -0800

saxparser 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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.