Matt Sergeant <msergeant@[...].uk>  writes:

> >>This is a feature release, introducing Perl extension functions to XSLT.
> > Hi, this is a great news!
> > Does it work with XML::LibXML->find too
...
> > and if not would it be hard to
> > implement it for those?
> 

>  I think it actually would be hard, because for raw XPaths you need to
>  register all the functions against an XPathParserContext thingy, which
>  we don't expose (yet) in XML::LibXML.
> 
>  I am willing to be proved wrong though, as I haven't gone into it in
>  too much detail - mostly I just copied the exslt code for this, which
>  is obviously different to anything involving pure XPath from libxml.

Ok, I took a quick look into LibXML.xs and xpath.c in XML::LibXML. The
function actually responsible for xpath search seems to be
domXPathFind. It creates a completely new xmlXPathContextPtr,
registers namespaces and the 'document' function and performs the
XPath evaluation via xmlXPathCompiledEval.

Now, let's say there is a generic wrapper in LibXML such as
LibXSLT_generic_function in LibXSLT that could be registered in favor
of any perl extension function with libxml2. The only problem here
would be to find some way to remember functions registered from
Perl-level and some way to tell domXPathFind what functions to
register these functions with libxml2 each time new ctx is created. It
might be important to decide whether the functions registered on
Perl-level sould be specific to a document or not. I suggest they're
not, so that they could be stored in some global (static) HV quite as
in LibXSLT.xs.

I've never written any XS code myself, so I might be completely wrong;
but from what I understand it does not seem to me that hard.

-- Petr
_______________________________________________
Perl-XML mailing list
Perl-XML@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs