Re: [xslt] XSLT extension API

[Thomas Broyer <tbroyer ltgt net>]

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

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.

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.

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

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

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

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.

Tom.