Hi, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> 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 _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
