[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    Re: Ideas for a GSOC 2013 Project
From:       Andreas Veithen <andreas.veithen () gmail ! com>
Date:       2013-04-22 18:57:21
Message-ID: CADx4_uVRqEEg3qr4LLuYxHdtsJ8bHZ4yu+6gPiKd5j42pyBtCA () mail ! gmail ! com
[Download RAW message or body]

On Sun, Apr 21, 2013 at 3:36 PM, Amila Suriarachchi
<amilasuriarachchi@gmail.com> wrote:
>
>
>
> On Sun, Apr 21, 2013 at 5:51 AM, Andreas Veithen <andreas.veithen@gmail.com>
> wrote:
>>
>> I see two important issues with that proposal:
>>
>> (1) The link with Axiom is actually much weaker than the proposal
>> suggests. It is correct that the current AXIOMXPath is tightly coupled
>> to Jaxen and that at some point we will need to define an abstract,
>> implementation independent API. However, that API would take as input
>> an Axiom tree and (if the XPath expression evaluates to a node set)
>> return a set of Axiom nodes. Since the proposed XPath implementation
>> takes as input an XMLStreamReader, it would not directly fit into that
>> API. One could of course extend the API to cover such implementations
>> as well, but at this point it is far from clear if that is the right
>> thing to do. In fact, I doubt that it would be good to use a single
>> API to cover both a full implementation of the XPath 1.0 spec (Jaxen)
>> operating on Axiom trees and a partial implementation (see point 2)
>> operating on XMLStreamReaders.
>>
>> Furthermore, looking at the initial architecture, there is actually no
>> dependency on Axiom. Ideally this proposal should be submitted to a
>> project that already has an XPath implementation, since this would
>> avoid to develop yet another XPath expression parser.
>
>
> I think you are correct.
>
> I think better to submit this proposal to Synapse to develop it as a module
> for synapse since the main use case for this is rely on there. So if you can
> prove this has better performance for CBR compared to Axiom Xpath then we
> can think of putting this as an independent module or putting under an
> another Xpath implementation. This is similar to what has happened with
> Axiom. Originally it has developed as a part of Axis2 and later moved to a
> separate project.
>

Yes, I think it's better to develop that under Synapse and to decide
later whether it should stay there or whether it's worth including it
into another project.

The proposal should also explain clearly what the Synapse scenarios
are that it attempts to improve. That's still not exactly clear to me.

>>
>>
>> (2) XPathEvaluator operates on an XMLStreamReader. This gives you two
>> options:
>>
>> a. Restrict the implementation to a small subset of XPath, so that
>> XPathEvaluator can evaluate the XPath expression by looking at each
>> event one at a time. That subset would be really small, and calling
>> the result an XPath implementation would be misleading. Also, it is
>> not certain that the scope of this would be large enough for a GSoC
>> project.
>>
>> b. Propose a design that would allow to implement the full XPath spec
>> (or at least a significant portion of the XPath spec). However, doing
>> this with streaming support is highly non trivial. Even for such a
>> simple XPath expression as /data/book[isbn='1-84356-028-3'] this is
>> not trivial.
>
>
> IMHO it is ok to try out the non trivial things.

The problem is that there is a huge difference in complexity between
a. and b., and the design is not the same at all. Starting with a. and
then trying to extend it to b. won't work.

> Basically this will be a
> more research project to develop some algorithms/designs for that. But for
> scope wise it is required to go through the XPath spec and come up with fair
> enough sub set.

"fair enough sub set" is too vague. The proposal should explain what
subset can be reasonably expected.

>
> thanks,
> Amila.
>>
>>
>> The problem is that your proposal suggests that you are going to do b.
>> (there is no mention of any restriction on the XPath features to be
>> implemented), but at the same time, the proposal doesn’t show that you
>> are aware of the complexity of that option and that you have concrete
>> ideas about the algorithms that would be required to implement that.
>>
>> Andreas
>>
>>
>> On Sat, Apr 20, 2013 at 11:41 AM, Isuru Ranawaka <irjanith@gmail.com>
>> wrote:
>> > hi ,
>> > I have attached the Proposal for XPath Implementation.
>> >
>> >
>> > On Mon, Apr 8, 2013 at 7:48 AM, Amila Suriarachchi
>> > <amilasuriarachchi@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Apr 8, 2013 at 2:31 AM, Andreas Veithen
>> >> <andreas.veithen@gmail.com> wrote:
>> >>>
>> >>> That would not be XPath, but a small subset of XPath. What parts of
>> >>> XPath are you planning to support?
>> >>
>> >>
>> >> IMHO we may be able to implement a whole Xpath spec. But take a fair
>> >> amount of practically used parts.
>> >>
>> >> But of Course we need to agree on what amount sufficient for a GSoc
>> >> project.
>> >>
>> >> thanks,
>> >> Amila.
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>> Andreas
>> >>>
>> >>> On Tue, Apr 2, 2013 at 8:49 AM, Isuru Ranawaka <irjanith@gmail.com>
>> >>> wrote:
>> >>> > hi Andreas ,
>> >>> >
>> >>> > Current Implementation of Streaming Xpath Parser is not support for
>> >>> > Xpath
>> >>> > expressions that having predicates. On the Other hand it Operates on
>> >>> > top of
>> >>> > the OMElement .What I suggest is rewrite Xpath Parser for evaluate
>> >>> > Xpath
>> >>> > Expressions on top Of the XMLStream.That means with out building
>> >>> > OMElement
>> >>> > or any Other Object Model getting XML Events From XMLStream and
>> >>> > Evaluate
>> >>> > Xpath. For that Xpath Compiler should have to be designed and Need
>> >>> > to
>> >>> > figure
>> >>> > out Object Model for represent Xpath Expression .By Using that Xpath
>> >>> > Model
>> >>> > and XMLStream it should be able to evaluate Xpath.
>> >>> >
>> >>> >
>> >>> > On Tue, Apr 2, 2013 at 12:44 AM, Andreas Veithen
>> >>> > <andreas.veithen@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> On Sun, Mar 24, 2013 at 9:19 AM, Isuru Ranawaka
>> >>> >> <irjanith@gmail.com>
>> >>> >> wrote:
>> >>> >> > 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.
>> >>> >>
>> >>> >> Can you explain how this would work for an expression like
>> >>> >> /data/book[isbn='1-84356-028-3']?
>> >>> >>
>> >>> >> Andreas
>> >>> >>
>> >>> >>
>> >>> >> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >>> >> For additional commands, e-mail: dev-help@ws.apache.org
>> >>> >>
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: dev-help@ws.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: dev-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: dev-help@ws.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]