Re: [xml] XPath expression portability framework dependance
- From: Daniel Veillard <veillard redhat com>
- To: Stefano Debenedetti <ste webaccess mozquito com>
- Cc: xml gnome org
- Subject: Re: [xml] XPath expression portability framework dependance
- Date: Thu, 26 Dec 2002 10:09:53 -0500
On Thu, Dec 26, 2002 at 03:57:27PM +0100, Stefano Debenedetti wrote:
Daniel Veillard wrote:
Registering the namespace in the XPath evaluation context is less
portable but easier to understand. Note that the XPath specification
was not done with the expectation it would be used standalone but
always in a framework (XSLT and XPointer originally) which were
defining the mechanism for the context initialization.
Now, this seems to me a very interesting topic because I have been
trying to use the current() XSLT function in a standalone XPath query
and I couldn't find a way to do that using the python bindings of
libxml2 +libxslt but both xalan and saxon XPath implementations support
it by default even in standalone XPath queries.
current() being an XSLT function it is not implemented in
the XPath core. Enough people complain that libxml2 is too big
compared to expat (grumpf ...)...
Is there a way to do use the current() function in a standalone XPath
using libxml2+libxslt too? Is it more standards-compliant than the
solution taken by xalan&saxon? Or is it that the framework-dependance of
XPath means that there is not a standard way to do that?
Standard, no. You can register functions at the C level to the
XPath core, that exactly what the libxslt library does when it is
initialized. I think this should be doable at the python level too
by calling the XSLT initialization function.
I am interested because this seems like potential XPath portability
problems between, say, an XForms implementation written in java and one
written in python....
It will always be a portability problem, because the API are not
standardized (and should not IMHO, the closest is the XPath DOM3 module).
My stand on not standardizing the APIs is that usually it ended up with
really bad ones, tied to a language, and in general unusable from C.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]