Re: [libxml++] patch to allow building without glibmm

[Stefan Seefeld <seefeld sympatico ca>]

Murray Cumming wrote:
> > MC> The API matters. Glib::ustring is an API to UTF8 code, and the strings
> > MC> are always UTF8.
> >
> > But _how_ does it matter? If it does, my patch must be breaking something
> > but I spend a lot of time reading the code and I couldn't find any place
> > where it did matter.
>
>
> It matters in the application if the document contains UTF-8 and you try
> to do the_string.substr(2) or the_string[3] or convert to upper or lower
> case in your document, or sort the strings. I recommend that you read the
> documentation for Glib::ustring.
>
> I don't believe that anybody can guarantee that their system will never
> need to support UTF-8.

It doesn't matter for the xml processing, but only on the application
level, once you start to actually *interpret* the data.
Thus, these two APIs (i.e. string vs. xml) are orthogonal, which is exactly
why this topic comes up again and again.

Users want to access the xml-related logic, leaving data interpretation
to the application. Thus they don't understand why they should be forced
into a (from their POV) unnecessary dependency.

We discussed the option of templatizing the library around the unicode
string type, which people didn't like. However, I believe there are other
options to insulate the string type, without having to a) depend on any
external library and b) requiring additional copies.

libxml++ could define its own string type, which would simply be some
kind of smart pointer. Then you could add conversion functions to and from
your favorit unicode implementation for convenience.
That way users still have the choice which unicode library to use (if any at all).

Regards,
		Stefan