Re: [xslt] libxslt escaping urls when outputting HTML#
- From: rm mh-freiburg de (Le grande pinguin)
- To: xslt gnome org
- Subject: Re: [xslt] libxslt escaping urls when outputting HTML#
- Date: Tue, 17 Sep 2002 14:00:00 +0200
On Tue, Sep 17, 2002 at 07:41:52AM -0400, Daniel Veillard wrote:
>
> yes they are hardcoded, because they are hardcoded in the specification,
> and if you want to provide your own serialization simply write your own
> version of xsltSaveResult... equivalent.
Yes, that's what i gathered from the sources. But given the use cases for
libxml2/lixslt i see this would mean writing my own versions of several
funcions (toFile/toBuffer etc.). So my first reaction was: this is a separate
level of functionality that could/should be factored out into an API.
> > As a long-term solution it might be interessting to have 'plugable' serializers,
> > but otoh there might be little common code left to serialisation once you have
> > plugins, so maybe you realy need to write your own serializer (the only benefit
> > speaking for the plugin aproach would be the ability to set the serializer from
> > within the stylesheet).
>
> Right I could make it easy by providing an API for new serialization
> methods provided by the user code.
>
> [...]
> > Lookin' forward to see the outcome ;-)
>
> The problem is that basically one need to duplicate the code of the
> HTML serializer, and this just for ensuring a "non conformant to the spec"
> behaviour that 99% of the users should not use. Understand it sounds like
> bloat to them ... the HTML serializer is part of libxml2, adding an xhtml
> serializer could be added reasonably but one just for not doing the
> processing that the HTML spec requires on URI-References when serializing,
> err it's just too much IMHO...
Understandable. At least in the context of XSLT serialization (which, in my
eyes is a bit strange anyway, since XSLT is pretty much serialisation-agnostic.
But that's another topic :-) In the context of libxml2 i think a dedicated
serialisation API could save some time (reuse of code for the different output
methods). And i can think of a lot of interesting serializers (LaTeX, Python/Perl
code etc.).
... just thinking loud myself
Ralf
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]