Re: [Re: [Re: [Re: [libxml++] UTF8 support]]]

[Murray Cumming <murrayc usa net>]

Stefan Seefeld <seefeld sympatico ca> wrote:
> As to the xml API shipping with Qt, I don't know it well. I think
> libxml2 is an excellent tool, and all it needs (to satisfy me :-) is a
> good C++ wrapper. DV told me the 'private' member in all the libxml2
> structs are there for exactly this purpose, so I started to write a C++
> wrapper around that. You know the rest...
> 
> Back to the point: I use this C++ wrapper in a couple of projects. I
> don't want to deal with more than one if not absolutely necessary.

I have really made up my mind but at the moment I am slightly against this API
change because:
1. I don't think _many_ people want to use libxml++ with a pre-existing
Unicode string class other than Glib::ustring. I do understand that you want
to personally but it's still hard to know what people want in general. I would
gladly hear from other people who want to use QString with libxml++, or some
other class.
2. I'm not sure that it's worth giving up the benefits of libxml++ being a
shared library just so that people don't have to write utility functions to
convert from Glib::ustring to their own string classes. In particular I'm
scared of asking people to recompile their apps just to get minor libxml++
implementation fixes.

Again, I haven't made up my mind. And again, I'm not sure. And because I'm not
sure I might write this up again later and ask for a vote.

Not that this, or the use of glibmm, would definitely go into the unstable
branch only anyway.

> There is currently no standard C++ API for XML processing.

The Xerces-C++ people have proposed one, to the W3C I think. But their API is
based on the Java API so I doubt that it's very C++-like.

> I'm
> considering to make a proposal to boost: http://www.boost.org. But of
> course, anything that will have a chance of getting in needs to be 
> generic, as standard (C++) compliant as possible, and well focussed...

I would welcome any input from the boost people about our discussion of Node's
"children" STL-like API and the alternatives that we mentioned.



Murray Cumming
murrayc usa net
www.murrayc.com