Hi Morris & Gary, Thank you for your response. I'd really like to try to do this. For the point #1 (enhancing lookup/resolving mechanism) I believe changes to XPath/Xalan code can be reduced to the very minimum. But for the point #2 (separating xpath and xslt extensions) changes might be quite noticeable. Plus they can be catagorized as architectural changes as they will involve design of extension interfaces in the xpath package.
Gary, I know you were majorily working on this mechanisms in the Xalan 2.X, so I'd really like to hear your opinion on all this before I start. Thanks, Dimitry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 10:06 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: xslt/xpath function extension mechanism I don't understand all the points in your note, but I agree with you that the current extension mechanism has some limitations. I think no other developer is working on the extensions at the moment. In case you want to try out a new design, remember to keep the changes to all of the existing classes minimum, and make the changes transparent to users who only use extensions in stylesheets. I think replacing the ExtensionHandler subclasses is OK. But it is better to keep the extension implementation classes (e.g. ExsltSets) intact. Gary Peskin ([EMAIL PROTECTED]) is the original developer of the current extension mechanism. You can also consult him for further details on extension resolving. Regards, Morris Kwan XSLT Development IBM Toronto Lab Tel: (905)413-3729 Email: [EMAIL PROTECTED] "Voytenko, Dimitry" To: Morris Kwan/Toronto/IBM@IBMCA, "'[EMAIL PROTECTED]'" <dvoytenko@sector <[EMAIL PROTECTED]> data.com> cc: Subject: RE: xslt/xpath function extension mechanism 01/17/2003 08:07 PM Please respond to xalan-dev Hi, Thanks for a prompt response. I'd like to discuss two changes to this system and I'd apreciate any comments/feedback on them. 1) Adopting package/function system for XPath extensions. Both packages and functions should be represented as interfaces. In this system call to ns:function() would be translated into the pair of two interfaces ExtPackage:ExtFunction. Interface ExtPackage will be responsible for resolving/lookup and instantiating of ExtFunction. And ExtFunction interface will be responsible for a runtime execution. I incline to this solution, b/c it can be fairly easy implemented in the C++. Basically this system has already been implemented in xpath/xalan packages: packages are implemented as the org.apache.xalan.extensions.ExtensionHandler class and its subclasses and functions implemented using java reflection API. Which ExtensionHandler should be used (ExtensionHandlerJavaClass, ExtensionHandlerJavaPackage or ExtensionHandlerExsltFunction) is decided inside of Xalan code and there's no way to affect it. If you take a look in the class org.apache.xalan.extensions.ExtensionNamespacesManager method registerUnregisteredNamespaces(), you'd find: ExtensionNamespaceSupport extNsSpt = defineJavaNamespace(ns); defineJavaNamespace method decides which Handler is to be used b/w ExtensionHandlerJavaClass and ExtensionHandlerJavaPackage. I want to suggest to put a resolve/lookup mechanism, that would decide which handler should be used based on the namespace URI. Such lookup mechanism can be implemented the same way as TransformerFactory or SAXFactory lookup implementations (i.e. using System properties), or XPathFactory.registerExtensionPackage (<namespace>, <extension handler>). Naturally present ExtensionHandlerJavaClass and ExtensionHandlerJavaPackage would work the same way they do now. This'd be controlled by lookup mechanism. For instance: a) Namespace URI is in the form "class:CLASSNAME" or "xalan:CLASSNAME" or "java:CLASSNAME" b) Namespace URI is in the form http://xml.apache.org/xpath/java#CLASSNAME c) none of other implementations has been found. In my belief this could be of benefit to a number of users, b/c this would: 1. Give an opportunity to use Java interfaces to users who want to use them 2. System will work similary to the standard org.apache.xpath.Function (and btw, this can be implemented as a functions of package with namespace URI, equal to NULL) 3. This system is implementable in the C++ (and is pretty much coherent with the current implementation). 4. URI's used as namespaces can be used to store IDL's or JavaDoc to make porting process easier and documented. 5. Name convention will be less dependable on Java 6. It'll be possible to control instance of the function on the stylesheet level (now it's only object or class level). 7. Variable-argument functions (such as concat) will be possible. 8. Using such lookup mechanism among with ExtensionsProvider's would make possible to controll extensions in global (for all XPath clients) and local (XSLT XPath client) scopes. 9. This will reduce the number of lookups, b/c it'll be possible to specify extensions in global scope, for all XPath clients (XPathAPI, XSLT) and they will be resolved only once. 2) Separation of XPath function and XSLT element extensions. As you've pointed out Xpath should not be dependent on Xalan code. It seems to me, that the only way to accomplish this is to seperate xpath function and xslt element extensions. Thus instead of one interface org.apache.xpath.ExtensionsProvider there would be two: org.apache.xpath extension provider (functions) and org.apache.xalan extension provider (elements). Of course in the Xalan package both these interfaces can be implemented by one class. I don't think using XSLT functions within the XPathAPI is necessary. Plus functions like FuncExtElementAvailable doesn't really belong to org.apache.xpath.functions package. In this case all interfaces I mentioned above can be easily moved to xpath package. In case you'd think this all makes sense, I put examples of what those interfaces might look like: package xpath: interface ExtPackage { // analog to present org.apache.xalan.extensions.ExtensionHandler ExtFunction getFunction (String localName); } interface ExtFunction { // analog to present org.apache.xpath.functions.Function XObject execute (ExpressionContext context, XObject args[]); } interface ExtResolver { // analog to present org.apache.xpath.ExtensionsProvider ExtPackage resolvePackage (String uri); // or ExtFunction resolveFunction (String uri, String funcName); } class XPathFactory { // ExtPackage getPackage (String uri); ExtPackage registerPackage (String uri, ExtPackage pkg); } Thanks, Dmitry E. Voytenko Software Engineer Sector Data, LLC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 17, 2003 07:09 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: xslt/xpath function extension mechanism I think the current extension mechanism is closed to finished. There is no major item in our development plan right now. Of course you are free to propose any enhancements to it. If users like to see those enhancements, we can put them into our plan. You can also contribute any enhancements yourself. >> 3. Usage of extensions among with xpath/XPathAPI There are two possible solutions to this problem. The first one is a simple solution. It will add an additional ExtensionsProvider parameter to the XPathAPI interfaces. The users need to implement the ExtensionsProvider themselves. And you cannot directly make use of the Xalan provided extensions in XPath. The second solution is a more complete one. It will make it possible to use Xalan extensions in XPath. This solution is more difficult and I don't have any idea how to implement it at the moment. The major obstacle is in the fact that the Xalan extensions are now implemented in the org.apache.xalan package, which is on top of the org.apache.xpath package. The XPath classes (e.g. XPathAPI) should not have dependency on any Xalan class. Regards, Morris Kwan XSLT Development IBM Toronto Lab Tel: (905)413-3729 Email: [EMAIL PROTECTED] "Voytenko, Dimitry" To: [EMAIL PROTECTED] <dvoytenko@sector cc: data.com> Subject: xslt/xpath function extension mechanism 01/16/2003 10:55 PM Please respond to xalan-dev Hi, I've got a question concerning current extension mechanism (the one using Java reflection). Is it considered finished? Do you plan any enhancements to it? I'd really like to participate in any sort of discussion on this topic, if this is possible of course. While I find current system sufficient for most of our needs, I have some questions/concerns that I want to find better solution for. Some of them are: 1. Difficulty to port from Xalan C++ to Java (at least currently they are pretty different). 2. Deployment/detection problems 3. Usage of extensions among with xpath/XPathAPI If this has been a concern for other users, could you please direct me to the mail thread or refer to the conclusions you'd come to. Thanks, Dmitry E. Voytenko Software Engineer Sector Data, LLC _____________________________________________________ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC _____________________________________________________ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC _____________________________________________________ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
