Lists Home |
Date Index |
- From: Paul Tchistopolskii <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 26 Dec 2000 15:26:59 -0800
----- Original Message -----
From: Jonathan Borden <email@example.com>
> Simon St.Laurent wrote:
> > Yes, but it might be interesting to create an 'XPath parser' which reads
> > XPath and spits out SAX events, making these critters a bit easier to
> > process and transform internally. Then maybe an XPath writer which takes
> > those events and reports them as XPath again.
> So what you want is an XPath grove parser.
> > If only I didn't have a firm January 1 deadline...
> There are 39 productions in XPath so developing the property set should
> take just a few hours :-) The thought involves how to *prune* the XPath
> grove into something more useful.
BTW, James Clark has published the yacc grammar for Xpath.
If I recall proprely, the worstest problem with Xpath was tokenization,
there are some tokens that are based on context.
If I recall properly, it took me one day to write the working
prototype of Xpath compiler, but then I realized that Xpath->SAX looks
Also, one can grab Xpath compiler from XT ( or SAXON )
XT code is cool. I don't know about SAXON - have not cheked it.