Re: [xslt] libxslt escaping urls when outputting HTML

[rm mh-freiburg de (Le grande pinguin)]

On Mon, Sep 16, 2002 at 11:36:27AM +0200, Philipp Dunkel wrote:
> If you remember we had this discussion about a month ago as well. Back
> then I gave up.
> I just wanted you to think about one thing:
> Invention is using things that exist in a totally unpredicted new way.
> There seem to be a lot of people having troubles with URL-escaping, some
> of them resorting to patching libxslt (I did for my own use, but did not
> distribute since I don't want to fork or even put down your great work,
> especially since in terms of experience and knowledge your are by far
> the better programmer). Now This part of libxslt is not really that much
> of a core functionality, that it really matters that much. 

This is a dangerous statement, to say the least. If it doesn't break 
_your_ code this doen't mean it doesn't break someones carefully 
crafted standard conformant code somewhere (no, not mine, i case you
ask :)

> 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 need it and modified libxslt according to my needs, but is that the
> right way to do things for an issue like that? I don't think so. So why
> not take a more practical approach and make this change choosable at
> init-time. It would eliminate this discussion and make everyone happy: A
> standards compliant parser by default. WIth some neat extras if you
> really need them for a specific instance.
> Now this is just a thought, and I presume you have had it before.Non the
> less, I would be quite interrested in hearing your reasoning about why
> not to follow a path like that.
> 
Well, the two possible solutions is see are:

 - since this is a problem of serialisation, why not modify the
   serialisation code? Write your own (copying Daniels html-
   serializer) version that does the wanted escaping.

 - Create an xslt extension function and use it in your transformation:

    <a href='{pd:ugly-escape(@href)}'>My link</a>



  Ralf Mattes