Re: [xslt] XSLT extension API

[Daniel Veillard <veillard redhat com>]

On Wed, May 16, 2001 at 01:57:36AM +0200, Thomas Broyer wrote:
> 
> Le 14/05/01 02:48:03, Thomas Broyer a écrit :
> > A module may use data shared by all its elements and functions (for
> > example, a database connection). A module must then provide functions to
> > allocate and free the data structure. These data structures are kept in
> > an hash table (the key is the namespace URI) in the evaluation context.
> 
> This is really needed to implement the EXSLT - Functions module, and many
> other extensions I guess.
> 
> The func:function element registers itself in an hash table whose keys are
> the name and namespace URI of the function it defines. This is where
> "module data" is needed.

  There is already something similar at the stylesheet level for
extension prefix<->URI registration.

  My take is that extension modules should be registered application
wide in a global way. Then at evaluation startup, the list style->nsDefs
is followed (and for all imported/included stylesheets too), then
an initialization function gets called returning the specifically allocated
data for this module (if any). At evaluation end a cleanup function is
called in a similar way.

  So there is 2 tables:
  
  one application wide which for each URI associates:
    - void * xsltExtInitFunction(xsltTransformContextPtr ctxt,
                                 const xmlChar *URI);
    - void * xsltExtShutdownFunction(xsltTransformContextPtr ctxt,
                                 const xmlChar *URI);

  one per transformation instance which for each URI associates:
    - void *extData;
    - a pointer to the application wide entry.

> It also registers a generic function as the callback for the defined
> function (calls xsltRegisterExtFunction with the name and namespace URI of
> the defined function and the generic function).

  Okay, done in xsltExtInitFunction()

> When an XPath expression is evaluated, the generic function is called. It
> retrieves the func:function node defining the current function (whose name
> is retrieved from the compiled expr) -- this is another place where "module
> data" is needed --, verifies and registers the parameters then evaluates
> the func:function element contents. func:result pushes its result on
> another stack (still in "module data") and the generic function pops it
> then pushes it as the result of the function.

  Okay

> I didn't checked whether it's already possible but we also need a way to
> stop evaluation of a template (without raising errors).
> This is needed for the func:result element.

  Hum, there is no such framework. This can be done using an extra value
in the xsltTransformContextPtr which will be reset before and tested after
calling an extension function.

> > An element may need (I don't know if it is really necessary) to do some
> > computation at parsing (stylesheet compiling) time (as the XSLT
> > decimal-format and key do for instance). The data structure is kept in an
> > hash table in the stylesheet directly.
> 
> Above registrations should actually appear here. Checks of allowed /
> forbidden attributes and attribute values should also be done when
> compiling the stylesheet.

  Hum, then xsltRegisterExtPrefix() need to be extended too !
What do you need there  ?

> > Maybe every element (not only top-level elements) should have this
> > "two-phases" processing scheme to allow them to precompute even context
> > dependant data
> 
> ...and check for "validity".

  Hum, I'm not sure I understand, the compilation code does this
kind of things at stylesheet loading in preproc.c

> XSLT doesn't state "validity" checking has to be done only when the element
> is instanciated (and since a DTD fragment, even non-normative, is provided,
> I assume such checks must be done when parsing/compiling).

  that's part of the TODOs, do more static error checking.

> libxslt doesn't comply with this behaviour: the following stylesheet
> doesn't generate any error.
> <xsl:stylesheet version="1.0"
>      xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <xsl:template match="never-called">
>   <out>
>         <xsl:param name="nothin"/>
>     <xsl:choose>
>         <foo/>
>     <xsl:when test="root > 1">OK</xsl:when>
>     <xsl:otherwise>KO</xsl:otherwise>
>     </xsl:choose>
>   </out>
> </xsl:template>
> </xsl:stylesheet>
> 
> Note that an xsl:param at the right place (at top-level or just after
> xsl:template>) lacking its name attribute is caught up, not the misplaced
> one nor the foo element.

  Right. more work is needed ! What I really noticed was the WF error
in the attribute :-)

  Sure libxslt is far from being finished...

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/