Hi, I will be working on improving the extension support in Xalan. One of the working items is the XSLTC integration. The ultimate goal is to have consistent syntax for extensions, so that the transformation is transparent and the user can use the same stylesheet, without considering which transformer (interpretive Xalan or XSLTC) is being used.
I have done an analysis on the following items and provided my estimations here. If you have any comments, please feel free to add them to the list. 1. Java extension XSLTC supports both static and instance Java extension methods right now. There are still problems in type translation. XSLTC only supports the Java format namespace declaration at the moment, whereas the interpretive Xalan also supports package and class formats. I am going to add that support to XSLTC and fix the type translation problems. Since the Java extension is the one being used most, this one will be given the highest priority. 2. EXSLT extensions XSLTC does not support EXSLT extensions right now. It is possible to reuse the EXSLT extension implementations provided by Xalan in XSLTC, by adding some glue code to FunctionCall.java so that the EXSLT extension classes are treated as regular Java extension classes. There would be a requirement that the xalan.jar file should be in the classpath if you want to compile a stylesheet using EXSLT, because the implementation classes are in xalan.jar. I think this requirement is reasonable given that XLSTC_DTM also has a dependency on some components in xalan.jar. I also need to do some cleanups on the ESXLT implementations in org.apache.xalan.lib before they can be reused by XSLTC. We need to change the signature of some functions to use more generic types in parameters and return values. We also need to remove the dependency on the ExpressionContext object from some extension functions, because a XSLTC translet does not have access to such an object at runtime. In summary, all EXSLT extensions can be reused although some interface cleanups might be needed. 3. nodeset extension XSLTC provides a nodeset extension function. But it is in a different namespace than Xalan. The goal is to use the same namespace (http://xml.apache.org/xalan) for the nodeset extension. This should not be difficult. We only need to add some namespace mapping code here. 4. SQL extension We cannot reuse the SQL extension in XSLTC at the moment. SQL extension makes use of the DTMManager object. The translet does not have access to this object at runtime right now. I think this will change after the XSLTC_DTM integration. From my discussion with Henry, I have a reason to believe that after the DTM integration the translet will be able to access the DTMManager and thus the current SQL extension code can be reused in XSLTC. 5. support for lxslt:component and script in XSLTC My understanding is that this is possible but requires more efforts than the other items. We need to provide support for the component and script nodes at compile time and add something in the runtime library to interact with the BSF manager. Since using XSLTC is to gain performance, and the usage of script will pull your lag behind, there might not be so many people who want to use script with XSLTC. It might still be ideal if we can support this. Given the analysis above, I will give this item a lower priority. I will look at it when time permits. 6. Redirect extension XSLTC provides an output element for redirect purpose. The thing we need to do here is to create a mapping between xsltc:output and the redirect:write element in Xalan. The case is similar with the nodeset extension. 7. PipeDocument extension We cannot reuse Xalan's implementation of the PipeDocument extension in XSLTC. It is possible to provide a XSLTC specific implementation. We need to add a new SyntaxTreeNode for compile time analysis and add some runtime hook to wrap the output of a translet to a DOM. I will also give it a lower priority. 8. evaluate extension After investigation, I think it is NOT possible to implement the evaluate extension in XSLTC, given the design constraints of XSLTC. XSLTC parses an XPATH expression into DOM iterator calls at compile time. However, the expression string passed to the evaluate extension is not known until runtime. We cannot do any translation from an XPATH expression string to Java code at the runtime of a translet. This is the only item I found to be impossible. I think we have to live with this restriction. Comments and new ideas are welcome. Regards, Morris Kwan XSLT Development IBM Toronto Lab Tel: (905)413-3729 Email: [EMAIL PROTECTED]
