I think that 1 and 2 only make sense as a single project (as described in AXIOM-367):
* The scope of 2 is not large enough for a GSoC project. * 2 is a prerequisite for 1, but 1 is also an important test to check that the design of the new API is correct. Regarding 3, can you give a definition of "streaming XPath parser"? Andreas On Sat, Mar 23, 2013 at 3:47 AM, Isuru Ranawaka <[email protected]> wrote: > hi all , > > I am a final year student from computer science and engineering department > of university of moratuwa. I would like to do a GSOC project .Some of the > prefered project ideas are as follows > > > 1. Improve AXIOMXpath for support for Xpath 2.0 > > currently AXIOM is only support for Xpath 1.0 which is used in jaxen > 1.1 .So upgrading Xpath 1.0 to Xpath 2.0 can be done by integrating Xpath > Processor such as psychoPath xpath 2.0 processor. basically it has loosely > coupled API with internal implementation and it has more than 80 production > rules.Xpath parsing is done via JFlex and CUP. > > > 2. Develop Abstract API for make AXIOM loosely couple with Xpath > Implementation. > > currently AXIOM is tightly coupled with jaxen 1.1 and it will hard to > replace with new Xpath implementations.So developing Abstract API with > reusing javax.xml.xpath which is independent from object model is another > idea. > > > 3. Implement Streaming Xpath Engine on top of the XMLStream. > > Available Streaming Xpath Parsers are implement on top of the AXIOM .So > this idea is to implement it on top of the XMLStream which can gain > performance than others.Here a Xpath Expression Compiler should be > implemented and have to figure out object model for evaluate XML Stream. > > > > I would like to work on a project above mentioned and please > send your thoughts and ideas . > > > > thanks > > isuru > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
