Re: 'Re: [xml] "Control over encoding declaration (prolog and meta)'

On Thu, Jan 15, 2004 at 05:26:43PM +0100, Kasimier Buchcik wrote:
DOM 3 LS - LSSerializer.writeToString

The output is written to a DOMString that is returned to the caller 
(this method completely ignores all the encoding information available).

  Right, ignoring all encoding information, then allows to serialize as
UTF-16, without keeping the encoding="" informations. So I don't
see the problem. To me you are the one wanting to preserve broken
informations in this context, the spec do not ask for it.

of a string containing a serialized document to be different of the
real encoding of the document for braindead interface decision is
where the stupidity lies. That's what must be fixed.

Hmm, Daniel I guess you don't like the people to call your 
implementation "braindead", and I guess the DOM people don't like it either.

  I have since the beginning of DOM, and when I was still a W3C employee
disagreed publicly about the fact that DOM was forcing the interface to
UTF-16 strings. It's the main reason I decided I would not try to
implement compliance to DOM in libxml. And yes I stick to the "braindead"
adjective in this case, computer performance nowadays is completely related
to cache efficiency, UTF-16 destroy cache locality, it's hence a very stupid
  If you really care about performances keep native encoding or UTF-8
strings. If you really want to stick something labelled as ISO-8891-1
as an UTF-16 strings, then the cost of converting the string in memory
should be considered only a minor problem compared to the zillion casting
between UTF-8 and UTF-16 that DOM imposes on you anyway.


Daniel Veillard      | Red Hat Network
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]