Re: [xslt] libxslt escaping urls when outputting HTML



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. 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.
> 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.

  Basically the problems are:
    - one more API changing the behaviour of the framework
    - one more global variable, which I try to chase down to the minimum

Of course it would be an "easy" solution, I would just prefer an "exact"
solution. 
Now I'm not 100% opposed to doing it, just reluctant ... Apparently
people have had troubles w.r.t. URI escaping in XSLT framework, like
it appears new APIs are being added to XPath-2.0 and/or XQuery 2.0.
If someone could do the research to what those may need in the future
and suggest a solution which would be ready for the long term I would
feel very inclined to apply/implement/follow it :-)

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]