Re: [libxml++] patch to allow building without glibmm
- From: Stefan Seefeld <seefeld sympatico ca>
- To: libxmlplusplus-general lists sourceforge net
- Subject: Re: [libxml++] patch to allow building without glibmm
- Date: Fri, 28 Oct 2005 10:32:28 -0400
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 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).
] [Thread Prev