Re: [xslt] [PATCH] xslt extensions as modules, take 2

[Mark Vakoc <thevakoc-xml yahoo com>]

--- Joel Reed <joelwreed comcast net> wrote:
> On a plugin enabled libxslt, when a function, top-level, or element
> can't be found in the appropriate standard hashes, we attempt
> to find a plugin like this:

It seems to me you are pushing the module handling too high in the food chain. 
Why not just create a stub for regular expressions and use the module loading
during it's init functions to load any required third party libraries and if
found register the available functions?

A potential problem I see is that extension functions I don't believe are
always found during stylesheet compilation but rather during the execution.  I
know I've had typos before when calling custom extensions and those are caught
only while applying the stylesheet.  If the extensions are only registered
during runtime you prevent them from being able to use the precompute
functionality normally called when compiling a stylesheet.  This also would
cause havoc perhaps with the extension module's init callback members

Seems to me the logic should be handled more by the user application than
within libxslt itself.  For years my application, based on runtime information,
loads particular xslt extensions depending on the environment they are run in. 
This is done prior to actually compiling/using any stylesheets.  If I were to
port the application to another platform it would me nice to have platform
agnostic module APIs, but I wonder if the module loading isn't better off being
the responsiblity of the library's consumer or within prebuilt libraries such
as libexslt.