It is embarrassed that i mix you with David Bertoni, sorry :-( 2010/4/11 David Carver <d_a_car...@yahoo.com>
> 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> <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 <zong...@ca.ibm.com> > > > >
