On Thu, Sep 12, 2013 at 4:05 PM, Asiri Liyana Arachchi <[email protected]> wrote: > Since there are no other processors which are object model independent, and > because of the fact that the Axiom provides a DOM implementation I think > integrating Psychopath Xpath Processor with Axiom is the option left if to > give Axiom XPath 2 support. > in the issue page you have mentioned that > "Because of (1) the work required to integrate PsychoPath with Axiom would > be to ensure that DOOM has a level of compliance to DOM that is high enough > to support PsychoPath. " > > what work need to be done to ensure this? >
The process should be as follows: 1. Write some test cases that use PsychoPath together with Axiom's DOM implementation. Ideally these tests should be integrated into the Axiom build, but this requires that the PsychoPath library be available as a Maven artifact from the central repository, which was not the case last time I checked. 2. Identify the DOM methods that cause problems and that need to be implemented/fixed. 3. Add test cases to axiom-dom-testsuite that provide test coverage for these methods. The test suite in axiom-dom-testsuite is executed twice during the Axiom build: once against Apache Xerces and once against Axiom's DOM implementation. This approach ensures that the covered code is compliant with the DOM specs (assuming that Xerces is compliant). 4. Make the required changes to the DOM implementation to make the test cases added in the previous step pass. If changes are required to existing code, ensure that the code has enough test coverage to avoid regressions. Steps 2 to 4 would have to be repeated until the tests developed in step 1 all succeed. Andreas > > Regards, > Asiri > > > > . > > > On Sun, Jul 7, 2013 at 3:42 PM, Andreas Veithen <[email protected]> > wrote: >> >> From the documentation: >> >> "Saxon supports these models by wrapping each external node in a >> wrapper that implements the Saxon NodeInfo interface. When nodes are >> returned by the XQuery or XPath API, these wrappers are removed and >> the original node is returned. Similarly, the wrappers are generally >> removed when extension functions expecting a node are called." >> >> That is very bad from a performance perspective. Jaxen uses a pattern >> [1] that avoids this, so that using Saxon would be a regression. >> >> Andreas >> >> [1] >> https://svn.apache.org/repos/asf/webservices/axiom/tags/1.2.14/modules/axiom-api/src/main/java/org/apache/axiom/om/xpath/DocumentNavigator.java >> >> >> On Sun, Jun 30, 2013 at 4:45 PM, Asiri Liyana Arachchi >> <[email protected]> wrote: >> > Hi all, >> > I am 3rd year undergraduate of Department of Computer Science and >> > Engineering, University of Moratuwa, Sri Lanka. >> > I would to like to work on the above project. >> > >> > I went through the discussion on the issue:AXIOM-367 page. As far as I >> > understood Saxon-HE is good choice if it supports integration with >> > object >> > models other than DOM. >> > >> > [1] " Support for Axiom, JDOM, JDOM2, XOM, and DOM4J is not available >> > "out >> > of the box" with Saxon-HE, but the source code is open source (in >> > sub-packages of net.sf.saxon.option) and can be compiled for use with >> > Saxon-HE if required. " >> > >> > Does this make Saxon-HE a viable option? >> > >> > [1] http://www.saxonica.com/documentation/sourcedocs/thirdparty.html >> > >> > Best, >> > Asiri >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
