Hi,
Thanks for a prompt response.
I'd like to discuss two changes to this system and I'd apreciate any
comments/feedback on them.
1) Adopting package/function system for XPath extensions. Both packages and
functions should be represented as interfaces.
In this system call to ns:function() would be translated into the pair of
two interfaces ExtPackage:ExtFunction. Interface ExtPackage will be
responsible for resolving/lookup and instantiating of ExtFunction. And
ExtFunction interface will be responsible for a runtime execution.
I incline to this solution, b/c it can be fairly easy implemented in the
C++.
Basically this system has already been implemented in xpath/xalan packages:
packages are implemented as the org.apache.xalan.extensions.ExtensionHandler
class and its subclasses and functions implemented using java reflection
API.
Which ExtensionHandler should be used (ExtensionHandlerJavaClass,
ExtensionHandlerJavaPackage or ExtensionHandlerExsltFunction) is decided
inside of Xalan code and there's no way to affect it. If you take a look in
the class org.apache.xalan.extensions.ExtensionNamespacesManager method
registerUnregisteredNamespaces(), you'd find:
ExtensionNamespaceSupport extNsSpt = defineJavaNamespace(ns);
defineJavaNamespace method decides which Handler is to be used b/w
ExtensionHandlerJavaClass and ExtensionHandlerJavaPackage.
I want to suggest to put a resolve/lookup mechanism, that would decide which
handler should be used based on the namespace URI. Such lookup mechanism can
be implemented the same way as TransformerFactory or SAXFactory lookup
implementations (i.e. using System properties), or
XPathFactory.registerExtensionPackage (<namespace>, <extension handler>).
Naturally present ExtensionHandlerJavaClass and ExtensionHandlerJavaPackage
would work the same way they do now. This'd be controlled by lookup
mechanism. For instance:
a) Namespace URI is in the form "class:CLASSNAME" or "xalan:CLASSNAME" or
"java:CLASSNAME"
b) Namespace URI is in the form http://xml.apache.org/xpath/java#CLASSNAME
c) none of other implementations has been found.
In my belief this could be of benefit to a number of users, b/c this would:
1. Give an opportunity to use Java interfaces to users who want to use them
2. System will work similary to the standard org.apache.xpath.Function (and
btw, this can be implemented as a functions of package with namespace URI,
equal to NULL)
3. This system is implementable in the C++ (and is pretty much coherent with
the current implementation).
4. URI's used as namespaces can be used to store IDL's or JavaDoc to make
porting process easier and documented.
5. Name convention will be less dependable on Java
6. It'll be possible to control instance of the function on the stylesheet
level (now it's only object or class level).
7. Variable-argument functions (such as concat) will be possible.
8. Using such lookup mechanism among with ExtensionsProvider's would make
possible to controll extensions in global (for all XPath clients) and local
(XSLT XPath client) scopes.
9. This will reduce the number of lookups, b/c it'll be possible to specify
extensions in global scope, for all XPath clients (XPathAPI, XSLT) and they
will be resolved only once.
2) Separation of XPath function and XSLT element extensions.
As you've pointed out Xpath should not be dependent on Xalan code.
It seems to me, that the only way to accomplish this is to seperate xpath
function and xslt element extensions.
Thus instead of one interface org.apache.xpath.ExtensionsProvider there
would be two: org.apache.xpath extension provider (functions) and
org.apache.xalan extension provider (elements). Of course in the Xalan
package both these interfaces can be implemented by one class.
I don't think using XSLT functions within the XPathAPI is necessary. Plus
functions like FuncExtElementAvailable doesn't really belong to
org.apache.xpath.functions package.
In this case all interfaces I mentioned above can be easily moved to xpath
package.
In case you'd think this all makes sense, I put examples of what those
interfaces might look like:
package xpath:
interface ExtPackage { // analog to present
org.apache.xalan.extensions.ExtensionHandler
ExtFunction getFunction (String localName);
}
interface ExtFunction { // analog to present
org.apache.xpath.functions.Function
XObject execute (ExpressionContext context, XObject args[]);
}
interface ExtResolver { // analog to present
org.apache.xpath.ExtensionsProvider
ExtPackage resolvePackage (String uri);
// or
ExtFunction resolveFunction (String uri, String funcName);
}
class XPathFactory { //
ExtPackage getPackage (String uri);
ExtPackage registerPackage (String uri, ExtPackage pkg);
}
Thanks,
Dmitry E. Voytenko
Software Engineer
Sector Data, LLC
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 07:09
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: xslt/xpath function extension mechanism
I think the current extension mechanism is closed to finished. There is no
major item in our development plan right now. Of course you are free to
propose any enhancements to it. If users like to see those enhancements, we
can put them into our plan. You can also contribute any enhancements
yourself.
>> 3. Usage of extensions among with xpath/XPathAPI
There are two possible solutions to this problem. The first one is a simple
solution. It will add an additional ExtensionsProvider parameter to the
XPathAPI interfaces. The users need to implement the ExtensionsProvider
themselves. And you cannot directly make use of the Xalan provided
extensions in XPath. The second solution is a more complete one. It will
make it possible to use Xalan extensions in XPath. This solution is more
difficult and I don't have any idea how to implement it at the moment. The
major obstacle is in the fact that the Xalan extensions are now implemented
in the org.apache.xalan package, which is on top of the org.apache.xpath
package. The XPath classes (e.g. XPathAPI) should not have dependency on
any Xalan class.
Regards,
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: [EMAIL PROTECTED]
"Voytenko,
Dimitry" To:
[EMAIL PROTECTED]
<dvoytenko@sector cc:
data.com> Subject: xslt/xpath function
extension mechanism
01/16/2003 10:55
PM
Please respond to
xalan-dev
Hi,
I've got a question concerning current extension mechanism (the one using
Java reflection). Is it considered finished? Do you plan any enhancements
to
it? I'd really like to participate in any sort of discussion on this topic,
if this is possible of course.
While I find current system sufficient for most of our needs, I have some
questions/concerns that I want to find better solution for.
Some of them are:
1. Difficulty to port from Xalan C++ to Java (at least currently they are
pretty different).
2. Deployment/detection problems
3. Usage of extensions among with xpath/XPathAPI
If this has been a concern for other users, could you please direct me to
the mail thread or refer to the conclusions you'd come to.
Thanks,
Dmitry E. Voytenko
Software Engineer
Sector Data, LLC
_____________________________________________________
Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
_____________________________________________________
Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
