Hi, Dimitry -- I think that, in general, the changes you propose sound good. It seems to me that this will generalize the lookup mechanism to handle a variety of URIs and break it up into a a two-tiered mechanism (package and function). Could this mechaism be further generalized to handle extensions elements on the Xalan side as well?
In any event, it's difficult for me to study things in detail without seeing your proposed code. But, you seem to have thought a lot about it so I'd say you should have at it. If you have any questions about the existing code that I can answer, I'd be glad to. As you know, Morris has done a lot of good work here as well and he can probably help also. One request I'd like to make is that error messages be improved when an extension cannot be loaded. The classloader hierarchy used would be extremely helpful. Gary > -----Original Message----- > From: Voytenko, Dimitry [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 21, 2003 12:14 PM > To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Cc: '[EMAIL PROTECTED]' > Subject: RE: xslt/xpath function extension mechanism > > > 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 >
