Actually, I'm involved with the PsychoPath component at eclipse.
Dave
On 04/11/2010 07:27 AM, ustbcoder wrote:
Hi David,
Initially, i am interested in implementing XSLT 2.0 for Xalan, then, i
discovered that merge with Xalan with PsychoPath will speed up this
project. You said "The Xerces-J 2.10 upcoming release using PsychoPath
as one of it's XPath 2.0 engines" , it seems that implement XSLT 2.0
for Xalan is in plan now, good to hear that, so many guys are eager to
see that come true,I am eager to do something for this huge
project. In fact, i hold "implement XSLT 2.0 for Xalan" as a GSoC 2010
project (you can find my proposal in attach file [1]), and Henry
Zongaro agree with me and promise to mentor me, as we know, you are
chairman of Apache Xalan community, if you can give me some advises or
support on GSoC website, it will help me a lot and help our project
win in GSoC proposal filter period, then i will have more then two
months to finish the project with all my strength. Expecting to work
with you guys longtimer Xalan developer, if you have time, give me
some hands, thank you :-)
[1] Project proposal "Implement XSLT 2.0 for Xalan"
Best regards
Xunlong Gui
2010-04-11
------------------------------------------------------------------------
ustbcoder
------------------------------------------------------------------------
*发件人：* David Carver
*发送时间：* 2010-04-11 21:40:21
*收件人：* ustbcoder
*抄送：* xalan-dev@xml.apache.org
*主题：* Re: implement XPath 2.0 function for xalan
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
