Hi Morris, >> If you do not change these (org.apache.xalan.lib) >> classes, there is nothing to worry. I only had to make minor changes to org.apache.xalan.lib.ExsltDynamic and org.apache.xalan.lib.sql.XConnection classes. I've checked, this classes are not supported by XSLTC. So they are safe.
>> ... So there is no >> need for you to make your extension code under org.apache.xpath work with >> XSLTC. Only the extension classes in org.apache.xalan.lib are shared by I wanted to accomplish the goal, when developing and using extensions will be easy for any processor in the Xalan family or XPath separately. This way, users would be free to choose b/w Xalan-J, XSLTC and Xalan-C (of course, all this ideas can be tried on the interpretive Xalan-J first). It seems to me, that the only valid way to do this is by creating set of public interfaces for the bordering part of XPath. I believe this would be quite dangerous and unnecessary (if possible at all) to give access to the whole XObject class. This seems to be the only unresolved point for me right now. If you believe that idea of creating set of public interfaces (for whole Xalan family or just for Xalan-J2) is too premature for now, I'll submit my changes in the current state to bugzilla as an enhancement (after I've tested them on extensions tests set). But since, these interfaces are intended to go public, this might create unnecassary compatibility problems in the future. Thanks, Dimitry -----Original Message----- From: Morris Kwan [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 07:14 To: Voytenko, Dimitry Cc: [EMAIL PROTECTED] Subject: RE: xslt/xpath function extension mechanism Hi, Dimitry I might not fully understand all of your points. I believe that you do not need to make any change on the XSLTC side. The XPathAPI interfaces are only for the interpretive Xalan. They do not work with XSLTC. So there is no need for you to make your extension code under org.apache.xpath work with XSLTC. Only the extension classes in org.apache.xalan.lib are shared by Xalan and XSLTC. The only concern is that if you make any changes in these classes, remember to keep them work with XSLTC. If you do not change these classes, there is nothing to worry. Regards, Morris Kwan XSLT Development IBM Toronto Lab Tel: (905)413-3729 Email: [EMAIL PROTECTED] "Voytenko, Dimitry" To: Morris Kwan/Toronto/[EMAIL PROTECTED], '[EMAIL PROTECTED]' <[EMAIL PROTECTED] cc: data.com> Subject: RE: xslt/xpath function extension mechanism 03/16/2003 09:03 PM Hi Morris, I got stuck over extension support in XSLTC. There are some specifics in it at the present type, that would force to change pretty big amount of code, before this can be accomplished. In particular, as I understood, all extensions are plugged in during compile-time. As I mentioned in one of the previous letters users can take advantage of both compile- and run-time approaches. In addition, Xalan/XPath specifications imply that model should be run-time. Another problem, as you noted in this letter, is the compatibility of the argument and result types. IMHO, the only way to resolve this problem is by creating set of interfaces, i.e. in addition to ExtFunction and ExtFunctionResolver interfaces constraint argument and return objects to implementations of some interface, that'd be something very close to org.apache.xpath.objects.XObject, but with limitted modification functionality. I understand that you avoid using org.apache.xpath in the xsltc. As an alternative W3C's org.w3c.dom.xpath doesn't look to me suitable or sufficient. I'm sure that you use caution creating new public interfaces, that's why I'm writing this here. In addition, it looks very likely, that such set of interfaces may soon come out as a part of javax family, as the number of different XPath users grows: eb-xml, xml db, XPathAPI, etc. In the other areas: Have you taken a look into changes I proposed? Do they make sense to you? Do I need to clarify some of my points? As I mentioned before I don't insist on org.apache.xpath.extensions.pkgs package, though it looks usefull to me. Thanks, Dimitry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 21, 2003 11:28 To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' Subject: RE: xslt/xpath function extension mechanism Hi, Dimitry I really appreciate your work to the new extension mechanism. I had a quick look at the class hierarchy. Now I have a few questions for you. 1. For the classes under org.apache.xpath.extensions.pkgs, how do you decide which functions are put into each class (e.g. PkgNumber, PkgString, etc)? 2. What changes will you make to the current extension implementation classes under org.apache.xalan.lib? Do you want to drop them completely or have them call the corresponding methods in the Pkgxxx classes? When you make changes to the extension classes, keep in mind that the extension implementations are shared by both Xalan and XSLTC. That is why we use generic types in the argument and return types of the extension functions. For example, for the Math.highest() function, the type of the parameter and return value is a org.w3c.dom.NodeList, instead of an XPath NodeSet. That is because XSLTC can only handle the more common w3c types. Morris Kwan XSLT Development IBM Toronto Lab Tel: (905)413-3729 Email: [EMAIL PROTECTED] "Voytenko, Dimitry" To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> <[EMAIL PROTECTED] cc: data.com> Subject: RE: xslt/xpath function extension mechanism 02/20/2003 09:11 PM Please respond to xalan-dev Hi, Here's what I have to say about changes I proposed earlier. Sorry for the delay, I meant to finish much earlier, but got really jammed at work. It is pretty much finished. There's just some cleaning that should be done to finalize this as I had to comment some of the code which could be simply removed, so it'd be easier to see what's changed and how. http://www.sectorbase.com/tmp/20030220.zip Package org.apache.xpath.extensions.pkgs is just a sample of what lower-level extensions may look like. I just collected set of functions provided in JavaScript and Oracle SQL, as it seems as they are sufficient for a pretty broad set of tasks. Please review these changes (Gary, Morris, ?) and send me your comments. I actually have no idea where to move from this point, so please send me other instuctions how to get this to future release too. Thanks, Dimitry _____________________________________________________ Revere Data, LLC, formerly known as Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC.
