Hi Morris, >> 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)?
I don't insist on these packages. I put them as an example. And in that case PkgNumber should be probably divided into PkgNumber and PkgMath packages. I decided that there would be some time gap, while these changes will be being applied, to decide better what standard packages we'd want to have and what they would contain. I belive, that there's common set of functions that's more or less sufficient, and it's not XPath 1.0 set. Mostly, I gathered information for them from SQL 92 and Oracle SQL functions library. It's a good example as often it's been around for a long while and I also liked the idea how they are used for formatting tasks. Plus I took bunch of functions from JavaScript standard objects: Math, Number, String. Another proposition is to make this list coherent with XPath 2.0 functions subset. This would make it easier for users to skip of most extension questions, that will be solved by the time they'll be ready to switch to XSLT 2 / XPath 2. Or we can try to ask users to vote on which extensions should be there, as these extensions will be available to any XPath client by default. >> 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? They are fine now. I decided on leaving them where they are now. All current extension mechanisms are valid. I tested them, they work as before. The only thing, is that they are not available to other XPath clients besides Xalan (not available in XPathAPI, etc). Later on we can consider moving some of them to XPath package. Some of these extensions, of course, will be duplicated by standard packages. We can just deprecate them for now (in the Xalan docs). My basic idea was not to remove present mechanisms, but provide layer b/w them and XPath, so that XPath libraries would intiate interaction -- so that the bunch of most common extensions will be implemented once and will be available to all XPath clients. Plus package/function system is common system for most developing systems (java, pl/sql, etc) and it'd make it easier to migrate code from Java to C++ and back. >> 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 Honestly I haven't looked into this issue and haven't tested XSLTC. I'm definitely going to do this though. I was developing my classes so that on the lower level they would use the same approaches as current basic extension mechanism, to ensure this basic mechanism would work w/o changes. Thus I believed I should be fined. In either case I believe this can be solved pretty easily. If not anything else, I added createXObject() method to ExtCallContext, where result objects can be adjusted. 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]> <dvoytenko@sector 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 _____________________________________________________ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
