Thanks Indika and Andreas for the feedback. Let's see what others have to say about $subject.
On Sun, Jul 24, 2011 at 5:56 AM, indika kumara <indika.k...@gmail.com>wrote: > Thank Andreas for the detailed information. > > I think the option 2 is great but seems a long-term solution. The > option 1 is an acceptable solution if there is an XPATH 2.0 engine > supporting custom object models effectively. > > ~ Indika > > On Sun, Jul 24, 2011 at 2:23 AM, Andreas Veithen > <andreas.veit...@gmail.com> wrote: > > Axiom uses Jaxen for its XPath support because Jaxen has an > > abstraction layer that allows to plug in any object model. The > > javax.xml.xpath API is also designed to support multiple object > > models, however AFAIK existing implementations only support DOM. That > > means that one would have to convert the entire message to DOM every > > time an XPath expression is evaluated. Obviously that is not a good > > thing to do. > > > > Since building and maintaining an XPath 2.0 implementation is out of > > the scope of the Axiom project, this leaves us with two reasonable > > options: > > > > 1. Find an existing XPath 2.0 implementation that has the same level > > of object model independence as Jaxen. If such an implementation > > exists, one would only have to write the glue code to integrate it > > with Axiom. > > > > 2. Use an Axiom implementation that not only implements enough of the > > Axiom API to support the Axis2 and Synapse runtime, but also provides > > a decent implementation of the DOM API so that an existing > > implementation of the javax.xml.xpath API can be used. This is not the > > case for DOOM: it doesn't implement the Axiom API well enough to run > > Axis2. I've been working for some time on a project [1] that provides > > this kind of implementation. It is making steady progress, but it is > > still very experimental and is only able to run some parts of the > > Axis2 runtime. > > > > Andreas > > > > [1] http://code.google.com/p/ddom/ > > > > On Fri, Jul 15, 2011 at 05:01, indika kumara <indika.k...@gmail.com> > wrote: > >> Heshan, I think the better option is to use the standard > >> javax.xml.xpath API, and try to avoid AXIOMXPath. It seems that saxon > >> supports javax.xml.xpath API. It should be a matter of configuring a > >> property to force to use Saxon implementation - just like XSLT > >> transformation, Schema validation. > >> > >> There may be a trade-off between flexibility and performance with the > >> selection of a standard API or AXIOMXPath. However, with OMSource > >> [3-4] or similar thing, you should be able to plug AXIOM XML model to > >> the XPATH engine in a standard way. So, effectively, you may be able > >> to get any performance gain (if there are) from the use of AXIOMXPath > >> with the standard way too. BTW, anything needs to be validated. > >> > >> Thanks, > >> > >> Indika > >> > >> [1] > http://download.oracle.com/javase/1.5.0/docs/api/javax/xml/xpath/package-frame.html > >> [2] http://www.saxonica.com/documentation/javadoc/index.html > >> [3] > http://svn.apache.org/viewvc/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/util/jaxp/ > >> [4] > http://ws.apache.org/axiom/apidocs/org/apache/axiom/om/impl/jaxp/OMSource.html > >> > >> On Fri, Jul 15, 2011 at 12:15 PM, Heshan Suriyaarachchi > >> <heshan.suriyaarach...@gmail.com> wrote: > >>> Hi Devs, > >>> Synapse currently does not support XPath 2.0. I am looking into a way > of > >>> adding this support for Synapse. > >>> SynapseXPath is written by extending AXIOMXPath which is using Jaxen. > Jaxen > >>> does not support XPath 2.0. That is the reason that we can not use > XPath 2.0 > >>> in Synapse. > >>> I would like to get your valuable feedback on the way to go with > $subject. > >>> > >>> [1] > >>> - > http://mail-archives.apache.org/mod_mbox/ws-dev/201107.mbox/%3ccamtot2qsuf2vb7pas_hln29_k3anwnywyceolq_s6ygtaas...@mail.gmail.com%3E > >>> [2] - https://issues.apache.org/jira/browse/AXIOM-367 > >>> -- > >>> Regards, > >>> Heshan Suriyaarachchi > >>> > >>> http://heshans.blogspot.com/ > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > >> For additional commands, e-mail: dev-h...@synapse.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > > For additional commands, e-mail: dev-h...@synapse.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Regards, Heshan Suriyaarachchi http://heshans.blogspot.com/
