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

[Daniel Veillard <veillard redhat com>]

On Thu, Jan 15, 2004 at 05:26:43PM +0100, Kasimier Buchcik wrote:
> ----------
> DOM 3 LS - LSSerializer.writeToString
> http://www.w3.org/TR/2003/CR-DOM-Level-3-LS-20031107/load-save.html#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
decision.
  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

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