RE: [xslt] Module initialization with built-in user-defined dataelements "meta" and "initialize-module"

["Buchcik, Kasimier" <k buchcik 4commerce de>]

Hi, 

> -----Original Message-----
> From: xslt-bounces gnome org [mailto:xslt-bounces gnome org] 
> On Behalf Of Daniel Veillard
> 
> On Sat, May 06, 2006 at 05:16:42AM +0400, Oleg A. Paraschenko wrote:
> > Hello Kasimier,
> > 
> > On Fri, 5 May 2006 10:42:26 +0200
> > "Buchcik, Kasimier" <k buchcik 4commerce de> wrote:
> > 
> > ...
> > >   <!-- The new meda data element of Libxslt. -->
> > >   <meta xmlns="http://xmlsoft.org/XSLT/";>
> > >     <!--
> > >       Initialize the module "urn:test:myTest" at compile-time.
> > >       The attribute @scope can be one of:
> > >       1) "global" - global storage of user-data for this module
> > >       2) "stylesheet-level" - per stylesheet-level storage of
> > >                               user-data for this module
> > >       -->
> > >     <initialize-module namespace="urn:test:myTest" 
> scope="global"/>
> > >   </meta>
> > ...
> > > 
> > > Comments and further ideas are appreciated.
> > 
> > I'd like to resist to this approach. The main problems are:
> > 
> > * It's an odd thing to see developer-level data (how to initialize a
> > module) on the user-level (XSLT stylesheet).

The problem is that we currently do that implicitely by specifying
"extension-element-prefixes"; if the module is not specified by
this attribute, then a module of extension functions gets initialized
not earlier than at transformation-time.

But I see your point, and am now convinced that specifying the meta
information in the stylesheet isn't a good idea.

> > * Stylesheet is polluted by a processor-specific spots. If I have my
> > extension module for xsltproc, xalan, saxon, I'm not happy to add
> > meta instructions for each of them.
> 
>   Yeah, I must admit I'm not fond of adding libxslt specific extension
> 
> > Probably the best place to inform xsltproc about how to initialize
> > an module is the module itself.
> 
>   Yup sounds way better from my viewpoint :-)

OK, I'll transfer the "meta" element into the trashcan.

I currently don't know how to solve the module initialization of
extension functions at compile-time; so, I'll reactivate (for the
refactored code) the effect, which initializes modules at
compilation-time via "extension-element-prefixes". It'll be adjustable
via a "strict" field on the compiler context. Those who rely
on this effect, certainly won't be happy to see their
transformations to produce race conditions.
Ideally the processor should, at compile-time, evaluate which
extension functions are used (by evaluating the XPath expressions)
and try to initialize the corresponding modules. So if we ever get
this far, the "extension-element-prefixes" workaround could be
disabled.

Regards,

Kasimier