[ http://nagoya.apache.org/jira/browse/XALANJ-1468?page=history ]
Henry Zongaro updated XALANJ-1468:
----------------------------------
Assign To: (was: Xalan Developers Mailing List)
type: New Feature (was: Bug)
Description:
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.
was:
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.
Environment:
Operating System: Other
Platform: Other
was:
Operating System: Other
Platform: Other
Priority: Major
Bugzilla Id: (was: 18684)
> XPath extension mechanism enhancements
> --------------------------------------
>
> Key: XALANJ-1468
> URL: http://nagoya.apache.org/jira/browse/XALANJ-1468
> Project: XalanJ2
> Type: New Feature
> Components: XPath
> Versions: CurrentCVS
> Environment: Operating System: Other
> Platform: Other
> Reporter: Dimitry E Voytenko
> Attachments: diff.txt, diff.txt, diff2.txt, org.apache.xpath.extensions.zip,
> org.apache.xpath.extensions.zip
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
