On Wed, Sep 11, 2002 at 03:10:23PM +0200, Petr Pajas wrote:
>  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 don't think we ever will for the ordinary DOM classes. actually the 
currently provided XPath functions are basicly ment for simple lookups
inside a DOM tree. IMHO to provide such functions in the DOM interface would 
confuse more than it helps.

>  > 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.

actaully this is done per query. since the XPath context is not cached,
addding all additional functions would cause quite an impact on 
performance.

>  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 am not shure if a naive extension of XML::LibXML::Node's find*() functions
would be a very useful idea. instead a separate class that provides a more
open interface to the libxml2's XPath API would be a better approach here. 

within such a class i assume it will not be _that_ difficult to handle such 
extensionsa as XML::LibXSLT does. the problem is at the current state there
is no such class. 

>  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.

no it is the correct approach, but someone has to do it :|

christian

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