Re: [xslt] libxslt escaping urls when outputting HTML
- From: Daniel Veillard <veillard redhat com>
- To: xslt gnome org
- Subject: Re: [xslt] libxslt escaping urls when outputting HTML
- Date: Mon, 16 Sep 2002 05:56:35 -0400
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]