DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18684>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18684 XPath extension mechanism enhancements Summary: XPath extension mechanism enhancements Product: XalanJ2 Version: CurrentCVS Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: org.apache.xpath AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The idea is to allow to plug extensions into XPath seperately from Xalan. The whole idea can be considered in the prospect of bigger project to seperate XPath from Xalan. There's growing number of clients that query XML documents using XPath. These include XPathAPI, config parsers, etc. My idea was to use ExtFunctionResolver, that would be passed to XPathContext to resolve extension functions on request. And in addition to provide static (common) library using package(namespace)/function system to resolve most ommonly used functions, since XPath 1.0 seems to lack too many. All other clients would extend XPath via these interfaces (including Xalan). Such system will bring a number of benefits: a) XPath will be more separated from Xalan and it'll be possible to use extension functions outside Xalan. b) System can be easily implemented in C++, thus extensions can be used in both (after porting procedure). Namespace URL's won't depend on java conventions. c) Since function resolvers can be specified on runtime level, it'll be easy to pass context information inside of function implementations. This seems to be a very usual request in mailing lists. d) Convertions can be reduced, especially in case of nodesets. I implemented set of classes and interfaces in the org.apache.xpath.extensions package and reimplemented dependant classes in the xpath and xalan packages. Attached are cvs diff file with existing classes and zip with new classes. For the changes attached I ran tests in the xml-xalan/test/tests/extensions package. All tests were passed with the same result as latest CVS build. Package org.apache.xpath.extensions.pkgs contains sample extensions I collected from SQL92, Oracle SQL and JavaScript. I don't insist on including them, but it seems to be a good idea to have commonly used functions inside of XPath package. As I said this task can be considered as a part of bigger idea to make XPath indendent on Xalan. This implies creating set of interfaces covering classes XObject and so on. This could yield better result, since giving access to users to the whole XObject class is quite dangerous. I decided against creating these interfaces now, b/c they would involve too big changes and distact attention from this particular task.
