Re: [Re: [Re: [Re: [libxml++] UTF8 support]]]
- From: Murray Cumming <murrayc usa net>
- To: <libxmlplusplus-general lists sourceforge net>, <libxmlplusplus-general lists sourceforge net>
- Subject: Re: [Re: [Re: [Re: [libxml++] UTF8 support]]]
- Date: Mon, 24 Feb 2003 16:53:46 -0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]