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 _____________________________________________________ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC _____________________________________________________ Revere Data, LLC, formerly known as Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC.
