Menu
▾
▴
libxmlplusplus-general
|
From: Kurt M. B. <kur...@ya...> - 2004-08-16 15:07:46
|
I agree that a generic C++ API for xml would be useful; one the closely matches: http://www.w3.org/DOM/. I think the only difference between libxml++ version 1 and 2.7 is the string type. That being the case, why not just make a typedef or a wrapper for the string type? On Sun, 2004-08-15 at 23:41, lib...@li... wrote: > Send Libxmlplusplus-general mailing list submissions to > lib...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general > or, via email, send a message with subject or body 'help' to > lib...@li... > > You can reach the person managing the list at > lib...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Libxmlplusplus-general digest..." > > > Today's Topics: > > 1. Re: LibXML++ Min Requirements/ diff between 1 & 2.7? (Stefan Seefeld) > > --__--__-- > > Message: 1 > Date: Sun, 15 Aug 2004 20:50:27 -0400 > From: Stefan Seefeld <se...@sy...> > To: lib...@li... > Subject: Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7? > Reply-To: lib...@li... > > Christophe de Vienne wrote: > > Thomas Jarosch wrote: > > > >>> I personnaly did not try to extract Glib::ustring. Can't help on this. > >>> However you don't need GTK+ to install glibmm-2.4, which depends only on > >>> glib. This make the dependencies much lower than you suggest. > >>> FYI: > >>> http://sourceforge.net/mailarchive/forum.php?thread_id=3923642&forum_id=127 > >>> > >>> > >> > >> > >> We do this in our custom RPM specfile: > >> > >> > > > > [snip big patch to get rid of Glib::ustring] > > > > Is there a particular reason for you to get rid if Glib::ustring ? > > > > Is there other people doing such a thing ? > > You may remember our discussion about this very point quite a while ago. > I was in a similar position, i.e. the company for which I was looking for > a solution was already using qt which has its own unicode API. > > I thus suggested to parametrize the code to make the (unicode) string type > a template parameter and the conversion between it and the internal xmlChar > type a template 'trait'. > Apparently everybody but me was happy with the move to hook libxml++ up > with glib, so I followed my suggested design on my own. The result ended > eventually on the boost.org list as a suggestion, but unfortunately I > didn't yet manage to finish a revision that follows all the (very good) > criticism I received on the boost mailing list. > > I still believe that a generic C++ API for xml would be a very useful > thing, but unfortunately I doubt for various reasons that libxml++ > in its current design can play this role. > > Regards, > Stefan > > > > --__--__-- > > _______________________________________________ > Libxmlplusplus-general mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general > > > End of Libxmlplusplus-general Digest |
|
From: Daniel V. <vei...@re...> - 2004-08-16 15:34:12
|
On Mon, Aug 16, 2004 at 11:07:43AM -0400, Kurt M. Brown wrote: > I agree that a generic C++ API for xml would be useful; one the closely > matches: http://www.w3.org/DOM/. which totally sucks because it mandates UTF-16 strings. There is a good reason I didn't tried to implement "real" DOM in libxml2, I woudn't have been conformant anyway because there i no way I would have agreed to constantly recode UTF-16 to UTF-8 and back. C++ API for DOM is defined as the output of C++ header generator on the CORBA bindings, eek :-( Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
|
From: Stefan S. <se...@sy...> - 2004-08-16 23:09:58
|
Daniel Veillard wrote: > On Mon, Aug 16, 2004 at 11:07:43AM -0400, Kurt M. Brown wrote: > >>I agree that a generic C++ API for xml would be useful; one the closely >>matches: http://www.w3.org/DOM/. > > > which totally sucks because it mandates UTF-16 strings. > There is a good reason I didn't tried to implement "real" DOM in > libxml2, I woudn't have been conformant anyway because there i no > way I would have agreed to constantly recode UTF-16 to UTF-8 and > back. C++ API for DOM is defined as the output of C++ header generator > on the CORBA bindings, eek :-( is it ? I'v never seen anything about an officially endorsed C++ xml API (DOM, SAX, whatever). In any case, I believe on the boost list the consensus was not to rewrite the java-like APIs in C++ but rather use C++ specific idioms as much as possible. While I would be satisfied in an implementation that wraps libxml2, boost people obviously want to be sure that an API that gets accepted is implementable by other backends, too. Regards, Stefan |
|
From: Christophe de V. <cde...@al...> - 2004-08-17 08:25:40
|
Stefan Seefeld a écrit : > Daniel Veillard wrote: > >> On Mon, Aug 16, 2004 at 11:07:43AM -0400, Kurt M. Brown wrote: >> >>> I agree that a generic C++ API for xml would be useful; one the closely >>> matches: http://www.w3.org/DOM/. >> >> which totally sucks because it mandates UTF-16 strings. >> There is a good reason I didn't tried to implement "real" DOM in >> libxml2, I woudn't have been conformant anyway because there i no >> way I would have agreed to constantly recode UTF-16 to UTF-8 and >> back. C++ API for DOM is defined as the output of C++ header generator >> on the CORBA bindings, eek :-( > > is it ? I'v never seen anything about an officially endorsed C++ xml API > (DOM, SAX, whatever). In any case, I believe on the boost list the > consensus > was not to rewrite the java-like APIs in C++ but rather use C++ specific > idioms as much as possible. > While I would be satisfied in an implementation that wraps libxml2, > boost people obviously want to be sure that an API that gets accepted is > implementable by other backends, too. Have you seen the new serialization module ? It includes XML as a possible archive format, which is even more generic since XML is just a backend to the lib. Regards, Christophe |
|
From: Stefan S. <se...@sy...> - 2004-08-17 11:03:41
|
Christophe de VIENNE wrote: > Have you seen the new serialization module ? It includes XML as a > possible archive format, which is even more generic since XML is just a > backend to the lib. yeah, I'v followed the discussions a bit though I didn't look inside yet. I wouldn't say it's more generic, it just serves a very different goal. The fact that it involves xml is pure coincidence ;-) Regards, Stefan |
|
From: Christophe de V. <cde...@al...> - 2004-08-17 11:49:46
|
Stefan Seefeld a écrit : > Christophe de VIENNE wrote: > >> Have you seen the new serialization module ? It includes XML as a >> possible archive format, which is even more generic since XML is just >> a backend to the lib. > > yeah, I'v followed the discussions a bit though I didn't look inside > yet. I tested it quickly (but not the xml backend). It's really powerfull. > I wouldn't say it's more generic, it just serves a very different > goal. The fact that it involves xml is pure coincidence ;-) It's indeed a very particuliar use of xml. Christophe |
|
From: Jonathan W. <co...@co...> - 2004-08-16 16:46:34
|
On Mon, Aug 16, 2004 at 11:07:43AM -0400, Kurt M. Brown wrote: > I agree that a generic C++ API for xml would be useful; one the closely > matches: http://www.w3.org/DOM/. > > I think the only difference between libxml++ version 1 and 2.7 is the > string type. That being the case, why not just make a typedef or a > wrapper for the string type? The typedef would have to live outside the library for it to be settable by users of the library - so might as well be a #define - eurgh. That would mean that binary versions of libxml++ were not compatible unless compiled with the same value for the #define - euuuurgh. The C++ way to do it, as Stefan suggests, is with templates. jon -- "Reality is that which, when you stop believing in it, doesn't go away." - Phillip K. Dick |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X