Hi Isuru,

On Sun, Mar 24, 2013 at 1:49 PM, Isuru Ranawaka <[email protected]> wrote:

> hi,
>
> 1. ) Streaming Xpath Parser is developed for a ESB which get AXIOM Object
> and traverse through it and get results.here the main concern is to improve
> the performance of xpath parsing by specifying specific rules relevant to
> the domain. (e.g if there is expression such as “/data/book”  it only give
> the first child element under the data element )  what i suggest is
> creating a XpathEngine which does not consume any external object model and
> it will operate on top of the XML Stream that means traverse xmlstream and
> evaluate xpath.
>

If i'm not mistaken, the approach taken by a streaming Xpath parser does
not apply for all cases? For example, if the user wants a specific element,
then he/she will have to use the normal way, since the above approach only
gets the first node or element which matches the given expression?

Have you already thought of how to handle this?

Thanks,
Kishanthan.

>
> 2.) I have read some background documents and tutorials about Operation
> and design of PsychoPathXpathProcessor  basically it Operates as follows
>
>                 1. Load the XML Document
>
> currently XMLDocument is load using DOM Package ,Xerces and it can be
> replaced with other packages by implementing wrapper  and it should be
> implemented in a way that inner functionality should not break.
>
>          2.  Initialize static and dynamic context in respect to the
> document root.
>
>                     this is done by internal packages.
>
>          3.  Parse the XPath 2.0 expression.
>
>                      this is done by external packages JFlex and CUP
>
>          4.  Statically verify the XPath 2.0 expression.
>
>          5.  Evaluate the XPath 2.0 expression in respect to the XML
> document.
>
>  both 4 and 5 are done internally.
>
> If internal functionality is tightly coupled with DOM is it possible  to
> integrate with DOOM component .
>
>
>
>
> On Sat, Mar 23, 2013 at 9:09 PM, Andreas Veithen <
> [email protected]> wrote:
>
>> 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]
>>
>>
>

Reply via email to