Re: [xslt] Embedded Stylesheets

We do all this ourselves. We already have a decoding system in place that is unified for HTML and XML and that scans the initial source for meta tags and xml encodings etc. and also works correctly with HTTP headers. By the time we've sent the data to libxml, it's been decoded.


On Aug 15, 2004, at 1:32 AM, Daniel Veillard wrote:

On Sat, Aug 14, 2004 at 05:11:53PM -0700, Dave Hyatt wrote:
Ok, looked into this further, and the issue is that WebCore has already
done the decoding into a UTF-16 buffer. So that's why we have to

You're loosing a lot of speed there, as a lot of XML is served as UTF-8 . But my main concern is that you will not be conformant that way and I fear this is gonna break horribly:

   for example

<?xml version="1.0" encoding="ISO-8859-1"?>

in isolation is well formed. If delivered with an HTTP header indicating

Content-Type: application/xml;encoding=UTF-8

  then it's not well formed anymore and vice versa. The HTTP header
in XML overrides the encoding declaration in the instance, it's stupid
but it's that way.

As a result if you make the conversion and loose the encoding you will
get well formedness errors from the XML parser for resources which
should be well formed because you decoupled encoding from parsing, and
that you can't do in XML. Please look about this, this will break
and no amount of testing from disk loading can ever show it.

specify this explicitly.  It turns out the bug was just further up in
my code and I was passing in the wrong string.  Everything works just
fine now even with the encoding override.

Okidoc :-) I'm cleaning up a number of bugs today, I will try an implementation of the include/import loading extensions.


Daniel Veillard | Red Hat Desktop team
veillard redhat com | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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