libxmlplusplus-general — Open discusions about libXML++

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

[Stefan S. <se...@sy...>]

Brandon Forehand wrote:
> Stefan Seefeld <se...@sy...> 2005-10-28 10:32:28 -0400:
> 
>>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).
> 
> 
> This seems like a fairly reasonable tradeoff.  Basically, it would be a
> thin wrapper class around xmlChar *, that only manages memory allocation
> and deallocation.  It could in fact be completely opaque and provide no
> interface for access.  One possible implementation would simply be an
> opaque wrapper of std::vector<xmlChar>.

not quite. That would incure a full copy of the string each time you
access content. The only reason to actually wrap xmlChar * in a class/struct
is type safety, and a tiny bit of convenience.

class String
{
public:
   String(xmlChar *d, bool owner = false);
   ~String();
   xmlChar const *data() const;
   size_t size() const;
private:
   xmlChar   *data_;
   bool const owner_;
};

When accessing libxml2-internal content, libxmlpp would
simple construct a String with owner=false. The compiler
should be able to optimize the String use away entirely.
On the other hand, if passing new content into libxmlpp,
the String object would own its data, so it can destroy it
at the end.

Anyways, you get the idea...

Stefan

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

[Brandon F. <b4...@us...>]

Stefan Seefeld <se...@sy...> 2005-10-28 10:32:28 -0400:
> 
> 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).

This seems like a fairly reasonable tradeoff.  Basically, it would be a
thin wrapper class around xmlChar *, that only manages memory allocation
and deallocation.  It could in fact be completely opaque and provide no
interface for access.  One possible implementation would simply be an
opaque wrapper of std::vector<xmlChar>.  Then all you would need is some
namespace level conversion functions to char* and Glib::ustring.  This
way you can put the Glib::ustring conversion function in a separate
header and only if someone wants it would they have a Glib dependency.

-- 
Brandon Forehand

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

[Daniel V. <vei...@re...>]

On Fri, Oct 28, 2005 at 10:32:28AM -0400, Stefan Seefeld wrote:
> 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.

I stopped all debate about this back when switching from libxml1 to libxml2
starting that all API ofthe library would only take UTF-8 string for
anything related to document content. Some people dislike having to do
the conversion themselve but at least the API is totally unambiguous.
To me anything which will depend on some user setting (locale or whatever)
is near impossible to support. 

    gchar
    typedef char   gchar;
    Corresponds to the standard C char type. 

to me is a fundamental error because it is assumed to be in the user locale.
Hence the xmlChar * type used in libxml2 API, which is UTF-8, hence platform
and environment neutral.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
vei...@re...  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

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

[Simon R. <sr...@in...>]

I'm new here and I'm not sure if this is the right forum for this
discussion to continue but the dependence on glibmm is a pain in the
neck for those of us who want the latest and greatest libxml++ on
Windows.  If someone can prove me wrong, great.

Simon

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

[Murray C. <mu...@mu...>]

On Thu, 2005-10-27 at 15:23 +0200, Vadim Zeitlin wrote:
> On Thu, 27 Oct 2005 10:16:43 -0300 Darko Miletic <da...@uv...> wrote:
> 
> DM> There is an easy solution for this problem. Just use libxml++ 1.0x. It 
> DM> works with std::string. I use it both on windows and linux and it works 
> DM> perfectly.
> 
>  In fact, as I wrote, I think that libxml++ 2.x works just fine with
> std::string too. Again, I might be missing something but from reading the
> code it looks like strings in libxml++ are used as just buffers containing
> characters and their internal encoding couldn't matter less.

The API matters. Glib::ustring is an API to UTF8 code, and the strings
are always UTF8.

> DM> The only drawback for this approach is if you need UTF-16 or UTF-32 
> DM> encoding. These are not supported by libxml++ 1.0x.
> 
>  Another important point, of course, is that any new features are probably
> added to the latest version only, aren't they? E.g. I'm eagerly looking
> forward to more high-level XML schema support in libxml++ and I don't think
> this is ever going to be added to libxml++ 1.x, will it?

Feel free to fork it or take maintainership and create a libxml++
1.1/1.2 version, adding features to libxml++ 1.0 without breaking the
API.

Murray

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

[Murray C. <mu...@mu...>]

On Thu, 2005-10-27 at 11:09 -0500, Browder, Tom wrote:
> I second the motion.  As the current caretaker of libxmlwrapp, I'm
> probably going to recommend to users to migrate to libxml++ when it
> loses its dependencies on the glibmm chain.

The patch would be for people who want to build from source, such as for
embedded systems. Most applications would depend on distro packages that
use the default, where of course glibmm is easily available.

Murray

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

[Simon R. <sr...@in...>]

Just adding my hand to the list of people who have not been able to
adopt libxml++ because of the glibmm dependency.  I would love to see a
patch of this kind added.

Simon

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

[Browder, T. <Tom...@fw...>]

I second the motion.  As the current caretaker of libxmlwrapp, I'm
probably going to recommend to users to migrate to libxml++ when it
loses its dependencies on the glibmm chain.

-Tom browder

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...]=20
> On Behalf Of Chris Coleman
> Sent: Thursday, October 27, 2005 8:23 AM
> To: Vadim Zeitlin
> Cc: lib...@li...
> Subject: Re: [libxml++] patch to allow building without glibmm
>=20
> Hi,
>=20
> I will cerainly make use of this.=20
>=20
> I've had issues getting libxml++'s dependancies to build for=20
> my projects, and have been seriously considering the use of=20
> xmlwrap instead due to the inconvenience of having glibmm as=20
> a dependancy.
>=20
> Cheers
> Chris
>=20
>=20
> >MC> > Also, I wanted to have a clean way to build libxml++ without=20
> >MC> > glibmm and so I've created the attached patch to do it.
> >MC>=20
> >MC> Sounds OK, though I don't think many people will really need it.
> >
> > One point doesn't make a convincing statistics, but I'm currently=20
> >participating in work on several different projects each of=20
> which had=20
> >initially chosen to use xmlwrapp instead of libxml++ just because of=20
> >this dependency. I'd like to use libxml++ instead but there=20
> is just no=20
> >way I'm going to make my project depend on GTK+ just because of this=20
> >(especially as there is no real need to use Glib::ustring here=20
> >apparently)
> >
>=20
> This message has been checked for viruses but the contents of=20
> an attachment may still contain software viruses, which could=20
> damage your computer system:
> you are advised to perform your own checks. Email=20
> communications with the University of Nottingham may be=20
> monitored as permitted by UK legislation.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course=20
> Free Certification Exam for All Training Attendees Through=20
> End of 2005 Visit http://www.jboss.com/services/certification=20
> for more information _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
>=20

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

[Darko M. <da...@uv...>]

Vadim Zeitlin wrote:
 >  Another important point, of course, is that any new features are 
probably
 > added to the latest version only, aren't they? E.g. I'm eagerly looking
 > forward to more high-level XML schema support in libxml++ and I don't 
think
 > this is ever going to be added to libxml++ 1.x, will it?

The 1.0x branch is still being maintained but you are right that no 
major changes will be added to this version.

The schema support was missing in 1.X but since you have the code you 
can add it yourself. It is, in fact, not so difficult. Never forget that 
libxml++ uses libxml2. For the best scheme support you will need the 
latest libxml2.

Darko

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

[Chris C. <cq...@Cs...>]

Hi,

I will cerainly make use of this. 

I've had issues getting libxml++'s dependancies to build for my 
projects, and have been seriously considering the use of xmlwrap instead 
due to the inconvenience of having glibmm as a dependancy.

Cheers
Chris


>MC> > Also, I wanted to have a clean way to build libxml++ without glibmm
>MC> > and so I've created the attached patch to do it.
>MC> 
>MC> Sounds OK, though I don't think many people will really need it.
>
> One point doesn't make a convincing statistics, but I'm currently
>participating in work on several different projects each of which had
>initially chosen to use xmlwrapp instead of libxml++ just because of this
>dependency. I'd like to use libxml++ instead but there is just no way I'm
>going to make my project depend on GTK+ just because of this (especially as
>there is no real need to use Glib::ustring here apparently)
>

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

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

[Vadim Z. <va...@us...>]

On Thu, 27 Oct 2005 10:16:43 -0300 Darko Miletic <da...@uv...> wrote:

DM> There is an easy solution for this problem. Just use libxml++ 1.0x. It 
DM> works with std::string. I use it both on windows and linux and it works 
DM> perfectly.

 In fact, as I wrote, I think that libxml++ 2.x works just fine with
std::string too. Again, I might be missing something but from reading the
code it looks like strings in libxml++ are used as just buffers containing
characters and their internal encoding couldn't matter less.

DM> The only drawback for this approach is if you need UTF-16 or UTF-32 
DM> encoding. These are not supported by libxml++ 1.0x.

 Another important point, of course, is that any new features are probably
added to the latest version only, aren't they? E.g. I'm eagerly looking
forward to more high-level XML schema support in libxml++ and I don't think
this is ever going to be added to libxml++ 1.x, will it?

 Regards,
VZ

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

[Darko M. <da...@uv...>]

Vadim Zeitlin wrote:
>  One point doesn't make a convincing statistics, but I'm currently
> participating in work on several different projects each of which had
> initially chosen to use xmlwrapp instead of libxml++ just because of this
> dependency. I'd like to use libxml++ instead but there is just no way I'm
> going to make my project depend on GTK+ just because of this (especially as
> there is no real need to use Glib::ustring here apparently).

There is an easy solution for this problem. Just use libxml++ 1.0x. It 
works with std::string. I use it both on windows and linux and it works 
perfectly.

The only drawback for this approach is if you need UTF-16 or UTF-32 
encoding. These are not supported by libxml++ 1.0x.

Darko

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

[Murray C. <mu...@mu...>]

On Thu, 2005-10-27 at 02:47 +0200, Vadim Zeitlin wrote:
>  Hello,
> 
>  I've searched this list archives for the reasons as to why libxml++
> requires glibmm when it would seem that it hardly uses any of its
> functionality but couldn't find any real answer. Sorry if I missed
> something but to me it looks that std::string could be used instead of
> Glib::ustring just as well: indeed, I've even seen in the archives a
> suggestion to typedef Glib::ustring as std::string instead of using the
> real class. Unfortunately, it's not quite that simple as in a few places
> Glib::ustring::bytes() is used and std::string doesn't have (nor need) this
> method. Also, I wanted to have a clean way to build libxml++ without glibmm
> and so I've created the attached patch to do it.

Sounds OK, though I don't think many people will really need it.

>  The patch is rather short so you can probably read it quicker than I can
> explain it, but nevertheless here is the summary:
> 
> 1. add --without-ustring configure option (off by default), when it is used
>    the (new) stub file libxml++/glibmm/ustring.h is used instead of the real
>    one

I'd prefer not to include a different filename. I wouldn't want some
people to think that the dummy implementation there is actually the real
ustring.

> 2. define LIBXML_USE_STD_STRING when this option is used, this can be also
>    used by MSVC users to build without glibmm under Windows
> 3. use LIBXML_USE_STD_STRING in a few places in the code to select between
>    Glib::ustring::bytes() and std::string::size(): this is a bit ugly, of
>    course, but the only other alternatives are to either derive
>    Glib::ustring from std::string or to define some STRING_BYTES() macro
>    and both of them have their problems as well -- but if it would be
>    preferrable to do it like this, please let me know and I'll redo the
>    patch
> 4. updated the docs to mention the changes above (not sure if the file
>    docs/manual/libxml++_without_code.xml is the right one to update, again,
>    please let me know if it isn't and I'll redo it)
> 
> 
>  I sincerely hope this patch can be applied as it makes building the
> library on non-Linux systems (even other Unices such as Darwin or HP-UX,
> IRIX, ... are problematic without speaking about building glibmm and all
> its dependencies under Windows)

There is an installer for Windows (I think it even includes libxml++
now). And glibmm (and gtkmm) build on almost all Unixes, even with the
proprietary compilers. TheWrittenWord.com provide binary packages.

Could you put the patch in bugzilla, please?

Murray

[libxml++] patch to allow building without glibmm

[Vadim Z. <va...@us...>]

 Hello,

 I've searched this list archives for the reasons as to why libxml++
requires glibmm when it would seem that it hardly uses any of its
functionality but couldn't find any real answer. Sorry if I missed
something but to me it looks that std::string could be used instead of
Glib::ustring just as well: indeed, I've even seen in the archives a
suggestion to typedef Glib::ustring as std::string instead of using the
real class. Unfortunately, it's not quite that simple as in a few places
Glib::ustring::bytes() is used and std::string doesn't have (nor need) this
method. Also, I wanted to have a clean way to build libxml++ without glibmm
and so I've created the attached patch to do it.

 The patch is rather short so you can probably read it quicker than I can
explain it, but nevertheless here is the summary:

1. add --without-ustring configure option (off by default), when it is used
   the (new) stub file libxml++/glibmm/ustring.h is used instead of the real
   one
2. define LIBXML_USE_STD_STRING when this option is used, this can be also
   used by MSVC users to build without glibmm under Windows
3. use LIBXML_USE_STD_STRING in a few places in the code to select between
   Glib::ustring::bytes() and std::string::size(): this is a bit ugly, of
   course, but the only other alternatives are to either derive
   Glib::ustring from std::string or to define some STRING_BYTES() macro
   and both of them have their problems as well -- but if it would be
   preferrable to do it like this, please let me know and I'll redo the
   patch
4. updated the docs to mention the changes above (not sure if the file
   docs/manual/libxml++_without_code.xml is the right one to update, again,
   please let me know if it isn't and I'll redo it)


 I sincerely hope this patch can be applied as it makes building the
library on non-Linux systems (even other Unices such as Darwin or HP-UX,
IRIX, ... are problematic without speaking about building glibmm and all
its dependencies under Windows) much, much simpler and so I believe this
patch could attract more users to this (otherwise excellent!) library.

 Thanks in advance,
VZ
diff -x autom4te.cache -x bin -x '*.sw?' -x .svn -x Makefile.in -N -r -u /tmp/libxml++-2.12.0/configure.in ./configure.in
--- /tmp/libxml++-2.12.0/configure.in	2005-09-07 22:41:25.000000000 +0200
+++ ./configure.in	2005-10-25 20:59:17.000000000 +0200
@@ -90,9 +90,25 @@
 
 AC_CHECK_HEADERS(string list map, , exit)
 
-PKG_CHECK_MODULES(LIBXML, libxml-2.0 >= 2.6.1 glibmm-2.4 >= 2.4.0)
+PKG_CHECK_MODULES(LIBXML, libxml-2.0 >= 2.6.1)
 
-GLIBMM_CHECK_PERL([5.6.0])
+AC_ARG_WITH(ustring,
+    AC_HELP_STRING([--without-ustring],
+                   [use std::string instead of Glib::ustring]),
+    ac_cv_use_glibustring="$withval"
+)
+if test "$ac_cv_use_glibustring" != "no"; then
+    PKG_CHECK_MODULES(GLIBMM, glibmm-2.4 >= 2.4.0, ,
+        AC_MSG_ERROR(dnl
+[Glib::ustring needed but not available: ${GLIBMM_PKG_ERRORS-please see error message above}.
+
+You may specify --without-ustring to use std::string instead.])
+    )
+    GLIBMM_CHECK_PERL([5.6.0])
+else
+    GLIBMM_CFLAGS="-I\$(top_srcdir)/glibmm"
+    AC_DEFINE(LIBXML_USE_STD_STRING)
+fi
 
 # Dummy conditional just to make automake-1.4 happy.
 # We need an always-false condition in docs/Makefile.am.
diff -x autom4te.cache -x bin -x '*.sw?' -x .svn -x Makefile.in -N -r -u /tmp/libxml++-2.12.0/examples/dom_parser_raw/main.cc ./examples/dom_parser_raw/main.cc
--- /tmp/libxml++-2.12.0/examples/dom_parser_raw/main.cc	2004-12-25 16:48:56.000000000 +0100
+++ ./examples/dom_parser_raw/main.cc	2005-10-26 16:42:36.000000000 +0200
@@ -23,7 +23,10 @@
 
 #include <iostream>
 #include <fstream>
-#include <glibmm/convert.h>
+
+#ifndef LIBXML_USE_STD_STRING
+  #include <glibmm/convert.h>
+#endif
 
 
 void print_node(const xmlpp::Node* node, unsigned int indentation = 0)
@@ -76,6 +79,20 @@
     std::string contents = read_from_disk(filepath);
     std::string contents_ucs2;
 
+#ifdef LIBXML_USE_STD_STRING
+    size_t wcSize = mbstowcs(NULL, contents.c_str(), 0);
+    wchar_t *ws = new wchar_t[wcSize+1];
+    if ( mbstowcs(ws, contents.c_str(), wcSize) == (size_t)-1 )
+    {
+      std::cerr << "mbstowcs() failed" << std::endl;
+    }
+    else
+    {
+      const char * const s = (char *)ws;
+      contents_ucs2.assign(s, s + wcslen(ws)*sizeof(wchar_t)/sizeof(char) + 1);
+    }
+    delete [] ws;
+#else // !LIBXML_USE_STD_STRING
     try
     {
       contents_ucs2 = Glib::convert(contents, "UCS-2", "UTF-8");
@@ -84,6 +101,7 @@
     {
       std::cerr << "Glib::convert failed: " << ex.what() << std::endl;
     }
+#endif // LIBXML_USE_STD_STRING/!LIBXML_USE_STD_STRING
 
     parser.parse_memory_raw((const unsigned char*)contents_ucs2.c_str(), contents_ucs2.size());
 
diff -x autom4te.cache -x bin -x '*.sw?' -x .svn -x Makefile.in -N -r -u /tmp/libxml++-2.12.0/glibmm/ustring.h ./glibmm/ustring.h
--- /tmp/libxml++-2.12.0/glibmm/ustring.h	1970-01-01 01:00:00.000000000 +0100
+++ ./glibmm/ustring.h	2005-10-25 20:50:00.000000000 +0200
@@ -0,0 +1,25 @@
+/* glibmm/ustring.h
+ * this file is part of libxml++
+ *
+ * copyright (C) 2005 by the libxml++ development team
+ *
+ * this file is covered by the GNU Lesser General Public License,
+ * which should be included with libxml++ as the file COPYING.
+ */
+
+/*
+   This is a replacement header used instead of the real glibmm/ustring.h when
+   we're configured to use std::string instead of Glib::ustring.
+ */
+#ifndef LIBXMLPP_GLIBMM_USTRING_H_
+#define LIBXMLPP_GLIBMM_USTRING_H_
+
+#ifndef LIBXML_USE_STD_STRING
+    #error "LIBXML_USE_STD_STRING must be defined if this header is included."
+#endif
+
+#include <string>
+
+namespace Glib { typedef std::string ustring; }
+
+#endif // LIBXMLPP_GLIBMM_USTRING_H_
diff -x autom4te.cache -x bin -x '*.sw?' -x .svn -x Makefile.in -N -r -u /tmp/libxml++-2.12.0/libxml++/Makefile.am ./libxml++/Makefile.am
--- /tmp/libxml++-2.12.0/libxml++/Makefile.am	2005-08-25 00:20:51.000000000 +0200
+++ ./libxml++/Makefile.am	2005-10-25 20:58:48.000000000 +0200
@@ -1,6 +1,6 @@
 SUBDIRS = parsers exceptions nodes io validators
 
-INCLUDES = -I$(top_srcdir) @LIBXML_CFLAGS@
+INCLUDES = -I$(top_srcdir) @LIBXML_CFLAGS@ @GLIBMM_CFLAGS@
 
 h_sources_public = libxml++.h attribute.h dtd.h document.h noncopyable.h keepblanks.h
 h_sources_private = 
@@ -21,7 +21,8 @@
                          exceptions/libexceptions.la \
                          nodes/libnodes.la \
                          io/libio.la \
-						 @LIBXML_LIBS@
+                         @LIBXML_LIBS@ \
+                         @GLIBMM_LIBS@
 libxml___2_6_la_SOURCES = $(cc_sources) $(h_sources_public) $(h_sources_private) $(cc_sources_private)
 
 # Install the headers:
diff -x autom4te.cache -x bin -x '*.sw?' -x .svn -x Makefile.in -N -r -u /tmp/libxml++-2.12.0/libxml++/parsers/domparser.cc ./libxml++/parsers/domparser.cc
--- /tmp/libxml++-2.12.0/libxml++/parsers/domparser.cc	2005-04-24 17:18:32.000000000 +0200
+++ ./libxml++/parsers/domparser.cc	2005-10-25 20:48:28.000000000 +0200
@@ -80,7 +80,13 @@
 
 void DomParser::parse_memory(const Glib::ustring& contents)
 {
-  parse_memory_raw((const unsigned char*)contents.c_str(), contents.bytes());
+  parse_memory_raw((const unsigned char*)contents.c_str(),
+#ifdef LIBXML_USE_STD_STRING
+                    contents.size()
+#else
+                    contents.bytes()
+#endif
+                    );
 }
 
 void DomParser::parse_context()
diff -x autom4te.cache -x bin -x '*.sw?' -x .svn -x Makefile.in -N -r -u /tmp/libxml++-2.12.0/libxml++/parsers/saxparser.cc ./libxml++/parsers/saxparser.cc
--- /tmp/libxml++-2.12.0/libxml++/parsers/saxparser.cc	2005-04-24 17:05:49.000000000 +0200
+++ ./libxml++/parsers/saxparser.cc	2005-10-25 20:49:51.000000000 +0200
@@ -186,7 +186,13 @@
   
 void SaxParser::parse_memory(const Glib::ustring& contents)
 {
-  parse_memory_raw((const unsigned char*)contents.c_str(), contents.bytes());
+  parse_memory_raw((const unsigned char*)contents.c_str(),
+#ifdef LIBXML_USE_STD_STRING
+                    contents.size()
+#else
+                    contents.bytes()
+#endif
+                   );
 }
 
 void SaxParser::parse_stream(std::istream& in)
@@ -242,7 +248,13 @@
   }
   
   if(!exception_)
-    xmlParseChunk(context_, chunk.c_str(), chunk.bytes(), 0 /* don't terminate */);
+    xmlParseChunk(context_, chunk.c_str(),
+#ifdef LIBXML_USE_STD_STRING
+                  chunk.size()
+#else
+                  chunk.bytes()
+#endif
+                  , 0 /* don't terminate */);
 
   check_for_exception();
 }
--- /tmp/libxml++-2.12.0/docs/manual/libxml++_without_code.xml	2005-02-11 14:25:14.000000000 +0100
+++ docs/manual/libxml++_without_code.xml	2005-10-27 02:30:34.000000000 +0200
@@ -53,6 +53,15 @@
     <para>Because Standard C++ has no string class that can fully handle UTF-8, libxml++ uses the Glib::ustring class from the glibmm library. Glib::ustring has almost exactly the same API as std::string, but methods such as length() and operator[] deal with whole UTF-8 characters rather than raw bytes.</para>
     <para>There are implicit conversions between std::string and Glib::ustring, so you can use std::string wherever you see a Glib::ustring in the API, if you really don't care about any locale other than English. However, that is unlikely in today's connected world.</para>
     <para>glibmm also provides useful API to convert between encodings and locales.</para>
+    <para>
+        All this being said, if you are absolutely sure that you don't need any
+        extra functionality of Glib::ustring, you can build the library without
+        glibmm and its dependencies. Under Unix this is done by specifying
+        <literal>--without-ustring</literal> in configure arguments and under
+        Windows you have to ensure that <literal>LIBXML_USE_STD_STRING</literal>
+        is defined in your project options and the directory glibmm is in the
+        compiler include path.
+    </para>
     </sect2>
  
     </sect1>

Fwd: [libxml++] segmentation fault on solaris 10

[Christophe de V. <cde...@gm...>]

---------- Forwarded message ----------
From: jane J <jan...@ya...>
Date: 17 oct. 2005 02:23
Subject: Re: [libxml++] segmentation fault on solaris 10
To: Christophe de VIENNE <cde...@gm...>


Hello Christophe,

Thank you very much for your help! However, I cannot
compile and install the version 1.0.5 on Solaris 10.
When  It run "make" command, it has the following
errors as in the attached file. My gcc (g++) (in
/usr/sfw/bin) version is 3.4.3, and the libxml2
version is 2.6.10. Attached file is the log
information when I tried to compile and install
libxml++ 1.0.5.

Looking forward to hearing from you!

Regards

Jane

--- Christophe de VIENNE <cde...@gm...> wrote:

> Hi Jane,
>
> You should definitely try and use the last version
> (1.0.5 on the 1.0.x branch).
> If you still have the problem, please precise what
> compiler you use,
> and send a complete backtrace.
>
> Regards,
>
> Christophe
>
> 2005/10/12, jane J <jan...@ya...>:
> > Hello,
> >  I'm a new user of libxml++ and solaris. I do need
> help for the
> > following problem:
> >
> >  when I use libxml++1.0.1 on solaris 10, it had
> the sementation fault
> > even I only tested the dom_parser example. I've
> already tried to put the
> > "xmlpp::Document::Init init;" in the main program,
> but it alway remind me
> > with a compile error of "the Init is
> > private".  What shall I do to fix this problem? or
> if the later version of
> > libxml++ had already fixed the problem?
> >
> > By using gdb, the fault occured (for the
> dom_parser example) at line:
> > >  Glib::ustring nodename =3D node->get_name();
> >  in the method:
> > > void print_node(const xmlpp::Node* node,
> unsigned int indentation =3D
> > 0)
> >
> >  Thank you very much!
> >
> >  Jane
> >
> >
> >  ________________________________
> >  Yahoo! Music Unlimited - Access over 1 million
> songs. Try it free.
> >
> >
>




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

root@db[219] ./configure
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for a BSD-compatible install... ./install-sh -c
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for Win32 Platform... no
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... egrep
checking for ld used by gcc... /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking for /usr/ccs/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/ccs/bin/nm -p
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 262144
checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for correct ltmain.sh version... yes
checking if gcc static flag  works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/ccs/bin/ld) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking whether the g++ linker (/usr/ccs/bin/ld) supports shared
libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/ccs/bin/ld) supports shared
libraries... yes
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
appending configuration tag "F77" to libtool
checking string usability... yes
checking string presence... yes
checking for string... yes
checking list usability... yes
checking list presence... yes
checking for list... yes
checking map usability... yes
checking map presence... yes
checking for map... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBXML_CFLAGS... -I/usr/include/libxml2
checking for LIBXML_LIBS... -lxml2 -lpthread -lz -lm -lsocket -lnsl
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libxml++/Makefile
config.status: creating libxml++/parsers/Makefile
config.status: creating libxml++/exceptions/Makefile
config.status: creating libxml++/nodes/Makefile
config.status: creating libxml++/io/Makefile
config.status: creating docs/Makefile
config.status: creating docs/reference/Makefile
config.status: creating docs/reference/Doxyfile
config.status: creating examples/Makefile
config.status: creating examples/dom_build/Makefile
config.status: creating examples/dom_parser/Makefile
config.status: creating examples/dom_parse_entities/Makefile
config.status: creating examples/dom_read_write/Makefile
config.status: creating examples/dom_xpath/Makefile
config.status: creating examples/sax_parser/Makefile
config.status: creating examples/sax_parser_entities/Makefile
config.status: creating examples/sax_parser_build_dom/Makefile
config.status: creating examples/sax_exception/Makefile
config.status: creating examples/import_node/Makefile
config.status: creating win32_msvc6/Makefile
config.status: creating win32_msvc6/examples/Makefile
config.status: creating libxml++-1.0.pc
config.status: creating libxml++.spec
config.status: executing depfiles commands

root@db[220] cat INSTALL
root@db[221] make
Making all in libxml++
Making all in parsers
if /bin/bash ../../libtool --tag=3DCXX --mode=3Dcompile g++
-DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1  -DLIBXMLPP_COMPILATION  -I. -I. -I../..
-I/usr/include/libxml2     -g -O2 -MT parser.lo -MD -MP -MF
".deps/parser.Tpo" -c -o parser.lo parser.cc; \
then mv -f ".deps/parser.Tpo" ".deps/parser.Plo"; else rm -f
".deps/parser.Tpo"; exit 1; fi
mkdir .libs
 g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\=
"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1 -DLIBXMLPP_COMPILATION -I. -I. -I../..
-I/usr/include/libxml2 -g -O2 -MT parser.lo -MD -MP -MF
.deps/parser.Tpo -c parser.cc  -fPIC -DPIC -o .libs/parser.o
 g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\=
"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1 -DLIBXMLPP_COMPILATION -I. -I. -I../..
-I/usr/include/libxml2 -g -O2 -MT parser.lo -MD -MP -MF
.deps/parser.Tpo -c parser.cc -o parser.o >/dev/null 2>&1
if /bin/bash ../../libtool --tag=3DCXX --mode=3Dcompile g++
-DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1  -DLIBXMLPP_COMPILATION  -I. -I. -I../..
-I/usr/include/libxml2     -g -O2 -MT saxparser.lo -MD -MP -MF
".deps/saxparser.Tpo" -c -o saxparser.lo saxparser.cc; \
then mv -f ".deps/saxparser.Tpo" ".deps/saxparser.Plo"; else rm -f
".deps/saxparser.Tpo"; exit 1; fi
 g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\=
"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1 -DLIBXMLPP_COMPILATION -I. -I. -I../..
-I/usr/include/libxml2 -g -O2 -MT saxparser.lo -MD -MP -MF
.deps/saxparser.Tpo -c saxparser.cc  -fPIC -DPIC -o .libs/saxparser.o
 g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\=
"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1 -DLIBXMLPP_COMPILATION -I. -I. -I../..
-I/usr/include/libxml2 -g -O2 -MT saxparser.lo -MD -MP -MF
.deps/saxparser.Tpo -c saxparser.cc -o saxparser.o >/dev/null 2>&1
if /bin/bash ../../libtool --tag=3DCXX --mode=3Dcompile g++
-DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1  -DLIBXMLPP_COMPILATION  -I. -I. -I../..
-I/usr/include/libxml2     -g -O2 -MT domparser.lo -MD -MP -MF
".deps/domparser.Tpo" -c -o domparser.lo domparser.cc; \
then mv -f ".deps/domparser.Tpo" ".deps/domparser.Plo"; else rm -f
".deps/domparser.Tpo"; exit 1; fi
 g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\=
"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1 -DLIBXMLPP_COMPILATION -I. -I. -I../..
-I/usr/include/libxml2 -g -O2 -MT domparser.lo -MD -MP -MF
.deps/domparser.Tpo -c domparser.cc  -fPIC -DPIC -o .libs/domparser.o
 g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\=
"
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"libxml++\"
-DVERSION=3D\"1.0.5\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1
-DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -DHAVE_STRING=3D=
1
-DHAVE_LIST=3D1 -DHAVE_MAP=3D1 -DLIBXMLPP_COMPILATION -I. -I. -I../..
-I/usr/include/libxml2 -g -O2 -MT domparser.lo -MD -MP -MF
.deps/domparser.Tpo -c domparser.cc -o domparser.o >/dev/null 2>&1
/bin/bash ../../libtool --tag=3DCXX --mode=3Dlink g++   -g -O2   -o
libparsers.la    parser.lo saxparser.lo domparser.lo
libtool: link: `/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../..//libs=
tdc++.la'
is not a valid libtool archive
*** Error code 1
make: Fatal error: Command failed for target `libparsers.la'
Current working directory /OraInstall/libxml++-1.0.5/libxml++/parsers
*** Error code 1
The following command caused the error:
failcom=3D'exit 1'; \
for f in x $MAKEFLAGS; do \
  case $f in \
    *=3D* | --[!k]*);; \
    *k*) failcom=3D'fail=3Dyes';; \
  esac; \
done; \
dot_seen=3Dno; \
target=3D`echo all-recursive | sed s/-recursive//`; \
list=3D'parsers exceptions nodes io'; for subdir in $list; do \
  echo "Making $target in $subdir"; \
  if test "$subdir" =3D "."; then \
    dot_seen=3Dyes; \
    local_target=3D"$target-am"; \
  else \
    local_target=3D"$target"; \
  fi; \
  (cd $subdir && make  $local_target) \
  || eval $failcom; \
done; \
if test "$dot_seen" =3D "no"; then \
  make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `all-recursive'
Current working directory /OraInstall/libxml++-1.0.5/libxml++
*** Error code 1
The following command caused the error:
failcom=3D'exit 1'; \
for f in x $MAKEFLAGS; do \
  case $f in \
    *=3D* | --[!k]*);; \
    *k*) failcom=3D'fail=3Dyes';; \
  esac; \
done; \
dot_seen=3Dno; \
target=3D`echo all-recursive | sed s/-recursive//`; \
list=3D'libxml++ docs examples'; for subdir in $list; do \
  echo "Making $target in $subdir"; \
  if test "$subdir" =3D "."; then \
    dot_seen=3Dyes; \
    local_target=3D"$target-am"; \
  else \
    local_target=3D"$target"; \
  fi; \
  (cd $subdir && make  $local_target) \
  || eval $failcom; \
done; \
if test "$dot_seen" =3D "no"; then \
  make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `all-recursive'
root@db[222]

Re: [libxml++] Searching nodes with ns prefix

[Darko M. <da...@uv...>]

togol machillan wrote:
> Thanks for the prompt reply.
> 
> If I am searching for an element not in the default namespace, then there should no error messages regarding namespace registeration. Thats exactly what is confusing because OWL namespace is not a default namespace as is defined in the following OWL file. 

What version of libxml2 are you using? Try with latest version. I had 
several problems with schema validation that where fixed in latest 
libxml2 (2.6.22) perhaps it will help you.

Darko

Re: [libxml++] Searching nodes with ns prefix

[togol m. <tog...@ly...>]

Thanks for the prompt reply.

If I am searching for an element not in the default namespace, then there s=
hould no error messages regarding namespace registeration. Thats exactly wh=
at is confusing because OWL namespace is not a default namespace as is defi=
ned in the following OWL file.=20

<?xml version=3D"1.0"?>

<!DOCTYPE rdf:RDF [
  <!ENTITY root                 "file:/C:/OntoCAPE/">
  <!ENTITY owl                  "http://www.w3.org/2002/07/owl">
  <!ENTITY xsd                  "http://www.w3.org/2001/XMLSchema">
  <!ENTITY rdf                  "http://www.w3.org/1999/02/22-rdf-syntax-ns=
">
  <!ENTITY rdfs                 "http://www.w3.org/2000/01/rdf-schema">
  <!ENTITY molecular_species    "&root;molecular_species.owl">
  <!ENTITY phase_system         "&root;phase_system.owl">
  <!ENTITY Example              "&root;Example_v1.owl">
  <!ENTITY substance            "&root;substance.owl">
]>

<rdf:RDF
    xmlns=3D"&Example;#"
    xmlns:rdf=3D"&rdf;#"
    xmlns:rdfs=3D"&rdfs;#"
    xmlns:xsd=3D"&xsd;#"
    xmlns:owl=3D"&owl;#"
    xmlns:molecular_species=3D"&molecular_species;#"
    xmlns:phase_system=3D"&phase_system;#"
    xmlns:substance=3D"&substance;#"
    xml:base=3D"&Example;"
>
=20
  <owl:Ontology rdf:about=3D"&Example;">
    <owl:imports rdf:resource=3D"&phase_system;"/>
    <owl:imports rdf:resource=3D"&molecular_species;"/>
  </owl:Ontology>

Now if I find the ontology node with the XPath expr "//owl:Ontology", the n=
amespace registration error is thrown. If I explicitly register the OWL nam=
espace using xmlXPathRegisterNs function, the error message does not appear=
 but the node set is still empty. It does not change even if I replace xmln=
s:owl=3D"&owl;#" by xmlns:owl=3D"http://www.w3.org/2002/07/owl".=20

Togol=20

----- Original Message -----
From: "Darko Miletic" <da...@uv...>
To: "togol machillan" <tog...@ly...>
Subject: Re: [libxml++] Searching nodes with ns prefix
Date: Sun, 16 Oct 2005 14:38:34 -0300

>=20
> togol machillan wrote:
> > Dear Members,
> >
> > I am facing the problem of finding nodes in an OWL file. The=20
> > importance of registering the namespace before calling the find()=20
> > function has been discussed before, but still the find function=20
> > in libxml++ v2.12 does not support this. I defined a new function=20
> > as follows.
> > The "undefined namespace prefix" error message does not appear=20
> > anymore, but the node set is still empty. I call the find()=20
> > function for the root node rdf:RDF of the owl document with the=20
> > XPath expr //owl:Ontology. If I add a check to see whether the=20
> > OWL namespace is already registered using xmlSearchNs(), it=20
> > returns the namespace pointer since for OWL, the namespace is=20
> > always defined in the root node. Can somebody please point out=20
> > where the problem is?
>=20
> Namespace needs to be registered ONLY if it is default namespace.=20
> Other namespaces are recognized properly. That means if you have=20
> xml file like this:
>=20
> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> <rootitem xmlns=3D"http://www.something.com/ns1"
>                   xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
>                   xsi:schemaLocation=3D"http://www.something.com/ns1 ns1.=
xsd"
>   version=3D"1.3">
>=20
> In this case you must register ns1.xsd before doing find. For=20
> example like this:
>=20
>        xmlXPathRegisterNs( ctxt,
>                            "ns1",
>                            "http://www.something.com/ns1");
>=20
> The when doing search you should prefix all nodes from default=20
> namespace with namespace name you registered:
>=20
>    node->find("//ns1:rootitem/otheritem");
>=20
> Not placing registered prefix for default namespace in xpath string=20
> is the most common error when using libxml++ or libxml2.
>=20
> Darko
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general


--=20
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow Pa=
ges

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as=
p?SRC=3Dlycos10

Re: [libxml++] segmentation fault on examples

[Christophe de V. <cde...@gm...>]

Hi,

2005/10/18, langlois yan <lan...@ya...>:
> Hi, thank you for your quick answer. It helped me very
> much. It is the first time I try to use a C++ program
> with a "tird party" library. So I have juste a few
> other questions.
>
> I try to compile the example with anothers g++ version
> :
>
> with g++ 3.4 there is no error,

which means that libxml++ itself was compiled with g++ 3.4 on your system.

> with g++ 3.3.2 there is a segmentation fault
> and with g++ 4.0 there is also a segmentation fault.
>
> Do you use g++ 3.4 to compile libxml++ ?

Some people do, some don't. It all depends on your system.

>
> I am not surprise that g++ 4.0 does not work.

It's unrelated : the problem you have is not that g++ 4.0 is good or
bad (I'd be surprised if anything in libxml++ makes it fail).

> But in
> your manual you say that g++ 3 should be good.So is it
> normal that g++ 3.3.2 is not good ? Is there a lot of
> diferences between g+3.3.2 and g++3.4 ?

I don't know. If you need more help on the c++ compiler, try the c++ newsgr=
oup.



Christophe

Re: [libxml++] segmentation fault on examples

[Christophe de V. <cde...@gm...>]

Hi Yan

2005/10/17, langlois yan <lan...@ya...>:
> Hi,
>
> I copied examples from the web site. I wrote my
> Makefile :
>
> CXXFLAGS+=3D $(shell pkg-config --cflags libxml++-2.6)
> LDFLAGS+=3D $(shell pkg-config --libs libxml++-2.6)
>
> all:
>         g++ -o main main.cpp ${CXXFLAGS} ${LDFLAGS}
>
> run:clean all
>         ./main
>
> clean:
>         rm -f *.o main
>
> I get a winnig during the compilation process :
> /usr/bin/ld: warning: libstdc++.so.6, needed by
> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.2/../../../libxml++-2.6.so,
> may conflict with libstdc++.so.5

It looks like you're linking against the libstdc++ of two different
versions of gcc.
The segmentation faults comes from this.
Be sure to use the same compiler to compile libxml++ and your program.


Christophe

[libxml++] segmentation fault on examples

[langlois y. <lan...@ya...>]

Hi,

I copied examples from the web site. I wrote my
Makefile :

CXXFLAGS+= $(shell pkg-config --cflags libxml++-2.6)
LDFLAGS+= $(shell pkg-config --libs libxml++-2.6)

all:
	g++ -o main main.cpp ${CXXFLAGS} ${LDFLAGS}
	
run:clean all
	./main

clean:
	rm -f *.o main

I get a winnig during the compilation process :
/usr/bin/ld: warning: libstdc++.so.6, needed by
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.2/../../../libxml++-2.6.so,
may conflict with libstdc++.so.5

Then during the execution of the binary I got a
segmentation fault. I try to force the use of
libstdc++.so.6. There is no warning anymore but the
segmentation fault is always here.

If it can help you I compile the DOM parser example
and the segmentation fault happen when I try to get
the name of the attribute of the file :

(gdb) run
Starting program: /home/.../testXML/main 
[Thread debugging using libthread_db enabled]
[New Thread 1079317024 (LWP 2690)]

Node name = example
Node name = example
     line = 4

  Node name = examplechild
Node name = examplechild
       line = 5

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1079317024 (LWP 2690)]
0x4002d92a in xmlpp::Attribute::get_name () from
/usr/lib/libxml++-2.6.so.2

Thanks Yan.


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: [libxml++] Searching nodes with ns prefix

[Darko M. <da...@uv...>]

togol machillan wrote:
> Dear Members,
> 
> I am facing the problem of finding nodes in an OWL file. The importance of registering the namespace before calling the find() function has been discussed before, but still the find function in libxml++ v2.12 does not support this. I defined a new function as follows.
> The "undefined namespace prefix" error message does not appear anymore, but the node set is still empty. I call the find() function for the root node rdf:RDF of the owl document with the XPath expr //owl:Ontology. If I add a check to see whether the OWL namespace is already registered using xmlSearchNs(), it returns the namespace pointer since for OWL, the namespace is always defined in the root node. 
> Can somebody please point out where the problem is?

Namespace needs to be registered ONLY if it is default namespace. Other 
namespaces are recognized properly. That means if you have xml file like 
this:

<?xml version="1.0" encoding="UTF-8"?>
<rootitem xmlns="http://www.something.com/ns1"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://www.something.com/ns1 ns1.xsd"
  version="1.3">

In this case you must register ns1.xsd before doing find. For example 
like this:

       xmlXPathRegisterNs( ctxt,
                           "ns1",
                           "http://www.something.com/ns1");

The when doing search you should prefix all nodes from default namespace 
with namespace name you registered:

   node->find("//ns1:rootitem/otheritem");

Not placing registered prefix for default namespace in xpath string is 
the most common error when using libxml++ or libxml2.

Darko

[libxml++] Searching nodes with ns prefix

[togol m. <tog...@ly...>]

Dear Members,

I am facing the problem of finding nodes in an OWL file. The importance of =
registering the namespace before calling the find() function has been discu=
ssed before, but still the find function in libxml++ v2.12 does not support=
 this. I defined a new function as follows.

NodeSet Node::find_with_ns(const std::string& xpath, const std::string& ns_=
prefix, const std::string& uri) const
{
  xmlXPathContext* ctxt =3D xmlXPathNewContext(impl_->doc);
  if (!xmlXPathRegisterNs(ctxt, (const xmlChar*)ns_prefix.c_str(), (const x=
mlChar*)uri.c_str())){
	  std::cout << "Namespace registered successfully" << std::endl;
  }
  ctxt->node =3D impl_;
...=20

The "undefined namespace prefix" error message does not appear anymore, but=
 the node set is still empty. I call the find() function for the root node =
rdf:RDF of the owl document with the XPath expr //owl:Ontology. If I add a =
check to see whether the OWL namespace is already registered using xmlSearc=
hNs(), it returns the namespace pointer since for OWL, the namespace is alw=
ays defined in the root node.=20
Can somebody please point out where the problem is?
=20
Thanks,

Togol=20=20=20

--=20
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow Pa=
ges

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as=
p?SRC=3Dlycos10

Re: [libxml++] segmentation fault on solaris 10

[Christophe de V. <cde...@gm...>]

Hi Jane,

You should definitely try and use the last version (1.0.5 on the 1.0.x bran=
ch).
If you still have the problem, please precise what compiler you use,
and send a complete backtrace.

Regards,

Christophe

2005/10/12, jane J <jan...@ya...>:
> Hello,
>  I'm a new user of libxml++ and solaris. I do need help for the
> following problem:
>
>  when I use libxml++1.0.1 on solaris 10, it had the sementation fault
> even I only tested the dom_parser example. I've already tried to put the
> "xmlpp::Document::Init init;" in the main program, but it alway remind me
> with a compile error of "the Init is
> private".  What shall I do to fix this problem? or if the later version o=
f
> libxml++ had already fixed the problem?
>
> By using gdb, the fault occured (for the dom_parser example) at line:
> >  Glib::ustring nodename =3D node->get_name();
>  in the method:
> > void print_node(const xmlpp::Node* node, unsigned int indentation =3D
> 0)
>
>  Thank you very much!
>
>  Jane
>
>
>  ________________________________
>  Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
>
>

Re: [libxml++] parse_stream with auto_ptr

[Tobias G. <lis...@e-...>]

Christophe de VIENNE wrote:

>Could you post a little program that reproduce your problem ?
>  
>

Sorry, it was my fault - I was compiling with g++ 3.3, while libxml++ was
compiled with 4.0. This constellation was working for weeks - using
auto_ptr with
libxml++ was the frist time, the ABI changes caused trouble.

bye,

Tobias

PS: I already wrote this yesterday, but somehow only replied to myself
instead of the list. Sorry folks!

[libxml++] Libxml++ Dependencies

[Browder, T. <Tom...@fw...>]

I would like to take a try at hacking libxml++ to reduce dependency on
gnome except for the Glib::ustring and of course libxml2.  One reason is
that I tend to use the latest version of g++ and that sometimes causes
C++ library problems if all the C++ dependencies are not recompiled.

Does anyone have a suggested tack?

I personally would like to see the appropriate source for the string
dumped into the libxml++ package, but I believe that Christophe said he
would prefer a liibrary split of glibmm.

And then I believe there is a locale dependency on glibmm but I am not
sure how to proceed there.

Ideas appreciated.

Thanks.

Tom Browder
Fax: 850-862-8055