ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Ideas for a GSOC 2013 Project
Date Sun, 21 Apr 2013 12:51:01 GMT
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.

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

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


Mime
View raw message