Re: [xslt] libxslt escaping urls when outputting HTML

["Jean T. Anderson" <jta bristowhill com>]

Le grande pinguin wrote:

>On Mon, Sep 16, 2002 at 11:36:27AM +0200, Philipp Dunkel wrote:
>
>>And the
>>behavior that is currently there is absolutely the right thing as a
>>default. But if it's not really a core issue, why not make it a runtime
>>option. I could, during initialization just call IllegalEscaping(1); and
>>the URL-escaping would be turned of and left up to me to do within the
>>XSL.
>>
>
>Please, _no_ more globals! If you use libxml in an environment where
>the library might be needed by several components of an application
>(webserver with loadable modules, for example) this setup is asking
>for trouble. Imagine module A loading libxml and setting IllegalEscaping to
>true. Then, at some point some serveradmin installs module B which happens
>to set IllegalEscaping to false, and all a sudden module A stops working
>the way it used to ...
>

I'm just a wee libxslt newbie with about 3 weeks experience, but I'll 
second this motion.

I'm working on integrating libxslt into a shared library and providing 
some support for xsltproc options. I'm having to create two distinct 
processes for executing requests: one for xsltproc options that get set 
at the thread level, such as --param, and another for options that get 
set at the global level, such as --verbose, --maxdepth, --nonet, and 
--novalid. (The fact that memory allocation routines and error handlers 
also get registered at the process level instead of the thread level 
aren't a problem for this particular application.)

It's threads like this one on escaping urls that remind me that I am far 
from having a handle on all the globals that are out there.

 -jean

Jean T. Anderson