If there is not functionality you need, then I would HIGHLY recommend
contributing patches back to the psychopath project. The Xerces-J 2.10
upcoming release using PsychoPath as one of it's XPath 2.0 engines, so
it can be intergrated with out having to fork the code necessarily.
If you don't see something you need, please consider contributing a
patch at:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=WTP%20Source%20Editing
File the enhancement/patch under the wst.xsl component where PsychoPath
is maintained.
I'm also the lead on the wst.xsl component, and will make sure that any
patches are given attention.
Dave
On 04/11/2010 06:17 AM, ustbcoder wrote:
Hi Henry,
These days, i was looking at PsychoPath document and source code and
studing it, apparently, PsychoPath does not support enough
user interface for Xalan to get all the necessary things such as get
XPath syntax tree. But merging Xalan and PsychoPath and use PsychoPath
as our org.apache.xpath package replacing solution for Xalan
is feasible, in fact, i have done some experiment merging job :-)
Regards
Xunlong Gui
2010-04-11
------------------------------------------------------------------------
ustbcoder
------------------------------------------------------------------------
*发件人：* Henry Zongaro
*发送时间：* 2010-04-11 20:47:00
*收件人：* xalan-dev@xml.apache.org
*抄送：* David Carver
*主题：* Re: implement XPath 2.0 function for xalan
Hi, Jesper.
Jesper Møller <jes...@selskabet.org> wrote on 04/01/2010 06:24:49 PM:
> I'm one of the committers on PsychoPath XPath 2 engine and would
> like to offer my input where I can help if this is a viable way.
>
> First off, I must confess that while I know XSLT pretty well, I've
> not studied Xalan-J in depth. However, from looking over the design
> document for Xalan-J version 2, I can spot three major obstacles in
> consuming PsychoPath from Xalan-J:
>
> 1) PsychoPath is not "streamy" yet
> 2) Type informations is not part of current interfaces.
> 3) How would the XLST-to-bytecode (XSLTC) fit in?
>
> Ad 1: This would have to come from PsychoPath itself, with
> inspiration from the Xerces-J XPath engine. Work has not been
> underway yet, which leads to point 2:
> Ad 2: The DOM, NodeIterator and Schema interfaces aren't rich enough
> for the type information we need in XPath 2 (and thus XSLT 2).
> Ad 3: I've tried a proof-of-concept of making a compiler in
> PsychoPath, but this is not under development at the moment. Can the
> compiler fall-back to the interpreted implementation?
>
> On top of this, there is interest (from within the PsychoPath
> project itself) to clean up the API quite a bit. The current way we
> deal with static and dynamic context is just not well thought out.
> It's not a big issue, but in the interest of embeddability of the
> XPath2 enigne itself, the notion of dynamic and static context needs
> to be cleaned.
>
> Other than that, I would think that merging the two projects is not
> required at all, Xalan-J should be able to simply consume PsychoPath
> once we have a decent API which can satisfy the requirements of both
> Xalan and Xerces. If not, I thing it would signify a design fault in
our API.
Thanks for your thoughts. I've spent a few minutes looking at some of
the PsychoPath documentation, and I have a few questions and comments:
1. What is the form of the input accepted by PsychoPath? Is it
restricted to taking a DOM (Level 2?) input tree - whose nodes might
implement the ItemPSVI interface of the Xerces XML Schema API?
2. Does PsychoPath expose its abstract syntax tree representation of
XPath expressions? I ask this because patterns in XSLT pose a special
problem. A pattern like a/b/c is most conveniently evaluated as
self::c[parent::b/parent::a] - and making that kind of transformation
is most conveniently performed on the abstract syntax tree
representation of the expression. So in order for Xalan-J to use
PsychoPath to perform XPath evaluation efficiently, it would probably
need to have access to the abstract syntax tree representation. That
entails a higher degree of coupling than I think would be possible by
having Xalan-J simply using the PsychoPath user API.
Similarly for XSLTC, though having the XSLT Java byte code generation
rely on PsychoPath to perform the XPath byte code generation would
certainly be possible, I think there would be a need to have
PsychoPath expose very specialized interfaces for byte code generation
that no casual user would be interested in.
3. Does PsychoPath expose facilities for plugging in user-defined
functions? Such a facility would be needed to allow an XSLT processor
to define stylesheet functions that could be used within XPath
expressions. Then of course there are other functions in XSLT that
could be invoked from an XPath expression in a stylesheet, some of
which are affected by declarations in the stylesheet: key,
format-number, etc.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro
XML Transformation & Query Development
IBM Canada Lab T/L 313-6044; Phone +1 905 413-6044
mailto:zong...@ca.ibm.com
