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
