ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <amilasuriarach...@gmail.com>
Subject Re: Ideas for a GSOC 2013 Project
Date Sun, 21 Apr 2013 13:36:25 GMT
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.


>
> (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. 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.

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/

Mime
View raw message