Re: libxml2 in gnome 1.4

[Daniel Veillard <veillard redhat com>]

On Fri, Mar 23, 2001 at 10:15:20AM -0800, Darin Adler wrote:
> on 3/23/01 9:28 AM, Miguel de Icaza at miguel ximian com wrote:
> 
> > We also need to figure out what the problems are with the new libxml1
> > (so I would appreciate if Maciej actually provided a detailed list of
> > the known problems)
> 
> It would be convenient if Maciej could figure out what the problems are
> without doing testing. But he can't. Given my conversation with him
> yesterday, I assume that the only problems he knows about are ones others
> told him about. He said he hasn't seen any trouble yet, but then again I bet
> he hasn't even compiled the new libxml yet -- he's pretty busy with other
> stuff.

  Basically the likely problems are (as other already have suggested):

 Loading:
    - having an XML file with non ascii content.
    - you parse it, libxml new version will probably give a warning
      if the encoding is not declared and then assume ISO-Latin-1 charset
      (a real parser is supposed to stop there but libxml1 will go on)
    - however the content as passed to the SAX callback or in the XML
      tree will be encoded in UTF8 (i.e. a variable lenght encoding
      using 2 bytes for [0x80 - 0xFF]). this is the difference in behaviour
      you will see at with libxml1 when loading, i.e. chars outside the
      ascii range will now be UTF8 encoded.
 Saving (assuming you have a DOM tree):
    - libxml new version will expect to have an UTF8 tree, if you try to
      save a tree where chunk where added outside the ASCII range or 
      not UTF8 encoded well the library will emit warnings (but i thing
      it will still try to serailize them using character references).
      
> I haven't seen problems yet either, but I haven't tried to test the
> non-Latin-1 scripts yet. I'm not really set up for it.
> 
> We just did a ton of testing with the programs using old libxml on various
> systems with different character encodings. Until we repeat that, we won't
> know if there are problems or not. Given my understanding of the change, I'm
> expecting some minor problems that will require new code to handle. Maybe
> Daniel can set me straight on this and explain why there won't be any
> problems -- I still don't fully understand all the issues.

  I hope the description is complete enough. I'm ready to try to work
problem out and help on the issue (well I wasn't supposed to work on this
currently but ...).

> We could go with "I tried it and it worked for me", ship it, and let our end
> users tell us what the problems are. My initial thought is that it's not a
> good idea and defeats the whole purpose of doing all the testing we already
> did on GNOME 1.4.
> 
> I don't see the value of having the one library be "right" if it doesn't
> really provide any tangible benefit. Can someone walk me through a specific
> example that will really happen with GNOME 1.4 and how it's better for the
> user if the new library is installed?

  Nautilus may not seen big benefits. Any program using libxml for doing
any kind of data exchange with other XML based apps will instantly switch
from something unworkable except for ASCII content to fully interoperable.
I also think that if you try to do any kind of support for asian character
ranges then the old libxml1 is completely unusable.
  Things like:
    - using WebDav for accessing a folder with a non ascii name
    - trying to exchange bookmarks or config files with internationalized
      content with KDE
    - XML RPCs of various sorts with not just ascii content (method names
      or string params).
  The list is as exhaustive as the uses of libxml for data exchange of
user provided data.

  Again my goal is not to destroy Gnome-1.4 release, if this doesn't
work out I will not release 1.8.12 before we can feel confident about
the result. In the meantime people like Ximian will still be able to
develop against the head version, verify that their programs runs
in an interoperable way and help ironing things out. Then a 1.4.1 
release can be made probably in a coupple of months. The best thing
Eazel can do now is spot the points where this breaks (I understand
you feel you have other urgent things to do, in this case hope the user
community will do the test and trials for you, and that this can be
fixed without eating too much of your time). I expect other people
compiling from CVS to also stop the problems, the galeon team has been
dynamic so far.

   I hope this clarifies the situation,

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/