xml-xalan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Zongaro <zong...@ca.ibm.com>
Subject Re: implement XPath 2.0 function for xalan
Date Sun, 11 Apr 2010 12:46:25 GMT
Hi, Jesper.

Jesper Møller <jesper@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:zongaro@ca.ibm.com

Mime
View raw message