libxmlplusplus-general — Open discusions about libXML++

Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

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

Christophe de VIENNE wrote:

> Can I see you work somewhere ? Although we choosed not to do that, I'm 
> interested to see how it looks like.

Sure. It's at http://groups.yahoo.com/group/boost/files/xml/,
though, as I said, it's quite old and doesn't incorporate any of the
suggestions made in the discussions on the boost ML. You may search
the boost mailing list for xml related discussions, also. These boost
discussions are always very instructive.

Regards,
		Stefan

Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

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

Stefan Seefeld wrote:

> Christophe de Vienne wrote:
>
>> Thomas Jarosch wrote:
>>
>>> 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 certainly remember, and that's partly why I'm asking, to see if the 
choice we made is good for the majority of users.

> 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.

Can I see you work somewhere ? Although we choosed not to do that, I'm 
interested to see how it looks like.

>
> 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.


You're probably rigth. Moreover we're looking more for stability right 
now. Features will be added of course, but we'll keep API compatibility 
as much as we decently can.


Regards,

Christophe

Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

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

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

Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

[Thomas J. <tho...@in...>]

> >>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=1
> >>27
> >
> >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 ?

Our code already deals with UTF8, so we would have to link Glibmm
+ rewrite the code. Don't think other people do this, too...

Thomas

Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

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

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 ?

Re: [libxml++] Memory leak in throwing exception

[Thomas J. <tho...@in...>]

> >>I could reproduce the problem, but I'm not sure it's related. Although I
> >>have no idea on what's going on. I'll investigate this a bit more and
> >>keep you informed. If you have any additional information let me know.
> >
> >Unfortunately not as I'm not familiar with the autoptr stuff.
>
> Ok I fixed the issue in the HEAD branch. The branch 1.0 will follow soon.

"Another job well done". That solves the mystery of the missing xmlFreeDoc ;-)

Cheers,
Thomas

Re: [libxml++] Memory leak in throwing exception

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

Thomas Jarosch wrote:

>>I could reproduce the problem, but I'm not sure it's related. Although I
>>have no idea on what's going on. I'll investigate this a bit more and
>>keep you informed. If you have any additional information let me know.
>>    
>>
>Unfortunately not as I'm not familiar with the autoptr stuff.
>  
>

Ok I fixed the issue in the HEAD branch. The branch 1.0 will follow soon.

Regards,

Christophe

Re: [libxml++] Memory leak in throwing exception

[Thomas J. <tho...@in...>]

> >http://bugzilla.gnome.org/show_bug.cgi?id=132014
>
> I did, but shame on me with the holidays I completely forgot it :-\

No problem, that's what bugzilla is for :-)

> I could reproduce the problem, but I'm not sure it's related. Although I
> have no idea on what's going on. I'll investigate this a bit more and
> keep you informed. If you have any additional information let me know.

Unfortunately not as I'm not familiar with the autoptr stuff.

Thomas

Re: [libxml++] Memory leak in throwing exception

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

Thomas Jarosch wrote:

>Hi Christophe,
>
>have you seen the addition I made to an old bugzilla entry?
>
>http://bugzilla.gnome.org/show_bug.cgi?id=132014
>  
>

I did, but shame on me with the holidays I completely forgot it :-\

I could reproduce the problem, but I'm not sure it's related. Although I 
have no idea on what's going on. I'll investigate this a bit more and 
keep you informed. If you have any additional information let me know.

Regards,

Christophe

[libxml++] Memory leak in throwing exception

[Thomas J. <tho...@in...>]

Hi Christophe,

have you seen the addition I made to an old bugzilla entry?

http://bugzilla.gnome.org/show_bug.cgi?id=132014

Cheers,
Thomas

Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

[Thomas J. <tho...@in...>]

> >What are the ABSOLUTE minimum requirements for using this package?
> >I know the requirements stated for version 2.6 & Higher on the sourceforge
> >site are libxml2 & glibmm-2.4, but glibmm-2.4 seems to require the GTK+
> >library, which creates more overhead.  The site mentions using a subset of
> >glibmm-2.4 that contains Glib::ustring but doesn't expand any further on
> > how to do this.
>
> 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:
# Remove glib::ustring stuff as we don't need it
perl -p -i -e "s/Glib::ustring/std::string/g" `find . -name *.cc`
perl -p -i -e "s/Glib::ustring/std::string/g" `find . -name *.h`
perl -p -i -e "s/glibmm\/ustring.h/string/" `find . -name *.cc`
perl -p -i -e "s/glibmm\/ustring.h/string/" `find . -name *.h

and apply this patch, too:

diff -u -r libxml++-2.6.1/configure.in libxml++.ustring/configure.in
--- libxml++-2.6.1/configure.in Wed May  5 15:01:34 2004
+++ libxml++.ustring/configure.in       Fri Jul  2 21:41:14 2004
@@ -39,7 +39,7 @@

 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)

 # Dummy conditional just to make automake-1.4 happy.
 # We need an always-false condition in docs/Makefile.am.
diff -u -r libxml++-2.6.1/libxml++-2.6.pc.in 
libxml++.ustring/libxml++-2.6.pc.in
--- libxml++-2.6.1/libxml++-2.6.pc.in   Wed May  5 11:38:22 2004
+++ libxml++.ustring/libxml++-2.6.pc.in Fri Jul  2 21:48:22 2004
@@ -5,7 +5,7 @@

 Name: libxml++
 Description: C++ wrapper for libxml
-Requires: libxml-2.0 glibmm-2.4
+Requires: libxml-2.0
 Version: @VERSION@
 Libs: -L${libdir} -lxml++-2.6
 Cflags: -I${includedir}/libxml++-2.6 -I${libdir}/libxml++-2.6/include

Hope that helps.

Cheers,
Thomas

Re: [libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

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

Moretti, Luciano (MED) wrote:

>What are the ABSOLUTE minimum requirements for using this package?
>I know the requirements stated for version 2.6 & Higher on the sourceforge
>site are libxml2 & glibmm-2.4, but glibmm-2.4 seems to require the GTK+
>library, which creates more overhead.  The site mentions using a subset of
>glibmm-2.4 that contains Glib::ustring but doesn't expand any further on how
>to do this.
>  
>

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=12784

>Also- What are the major differences between V1.0 & V2.7?  I'm looking at
>the potential of using the old version because of it's lower dependencies.
>  
>

2.6:
- use of Glib::ustring instead of std::string.
- Addition of TextReader interface

2.7:
- Addition of Validator and DtdValidator



Regards,

Christophe

[libxml++] LibXML++ Min Requirements/ diff between 1 & 2.7?

[Moretti, L. (MED) <Luc...@me...>]

What are the ABSOLUTE minimum requirements for using this package?
I know the requirements stated for version 2.6 & Higher on the sourceforge
site are libxml2 & glibmm-2.4, but glibmm-2.4 seems to require the GTK+
library, which creates more overhead.  The site mentions using a subset of
glibmm-2.4 that contains Glib::ustring but doesn't expand any further on how
to do this.

Also- What are the major differences between V1.0 & V2.7?  I'm looking at
the potential of using the old version because of it's lower dependencies.


Thank you,

Luciano Moretti

Re: [libxml++] Ver. 2.6 vs 2.7 installation question

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

Hi,

Vladislav Grinchenko a écrit :

>[...]
>DISCUSSION:
>
>It seems that as far as pkg-config tool is concerned, the *.pc
>file should have the same name in all 3 cases rather then
>
>case 1 : /usr/lib/pkgconfig/libxml++-1.0.pc
>case 2 : /usr/lib/pkgconfig/libxml++-2.6.pc
>case 3 : /usr/lib/pkgconfig/libxml++-2.6.pc
>
>Is there a problem with the way case 1 packages the files?
>Should then name of PC file be libxml++2.6.pc in all 3 cases?
>  
>

This allow to have different versions of libxml++ cohexists on the same 
system. The last two (2.6 and 2.7) have the same name because 2.7 API is 
binary compatible with 2.6 API.

>The installation itself is confusing too:
>
>case 1 : /usr/include/libxml++-1.0
>case 2 : /usr/include/libxml++-2.6
>case 3 : /usr/include/libxml++-2.6
>
>case 1 : /usr/lib/libxml++-0.1.so
>case 2 : /usr/lib/libxml++-2.6.so
>case 3 : /usr/lib/libxml++-2.6.so
>
>Looks like there is no version difference between 2.6 and 2.7 ???
>But according to http://libxmlplusplus.sourceforge.net/, 2.6 and 2.7
>have different APIs but they suppose to work just fine with 
>libxml2 >=2.6.1 and glibmm-2.4 >=2.4.0.
>  
>
2.7 API only add new interfaces to 2.6, and their are (well, at least 
should be) binary compatible.

>BTW, here is the place where I've got RPM from:
>http://dag.wieers.com/packages/libxml++/
>
>And this is THE ONLY place where I could get libxml++ RPMs from.
>I wouldn't mind building my own RPM from a tarball, but for 
>installations without development environment, this is out of
>question. I should be able to point my users to some RPM repository
>with sane properly built libxml++ RPMs.
>  
>
No official RPM exists. See this thread : 
http://sourceforge.net/mailarchive/message.php?msg_id=4317457

>Sounds like the RPM is wrong and for all libxml++-2.k.x where k >= 6,
>they all should be identified as libxml++-2.6.pc and should
>all install in $prefix/include/libxml++-2.6 and so forth.
>  
>
If the problem is related to the RPM, you should see that with the 
person who makes it.


>Conclusively, 'configure.in' should test for:
>
>
>PKG_CHECK_MODULES(XMLCPP, libxml++-2.6 >= 0.26.0)
>AC_SUBST(XMLCPP_CFLAGS)
>AC_SUBST(XMLCPP_LIBS)
>
>The only problem I have with this approach is that it doesn't 
>mirror libxml2's structure itself (but perhaps it shouldn't):
>
>  
>
I'm not sure to get what you mean here


Regards,

Christophe

[libxml++] Ver. 2.6 vs 2.7 installation question

[Vladislav G. <3rd...@co...>]

Hi,

first off, thanks for writing and maintaining libxml++ - it greately
simplifies parsing XML files.

I have an app that used ver libxml++-0.26.0 till now on
Fedora Core 2 with libxml2-2.6.8.

The question I have is about a proper way of detecting
the version (and cflags/libs parms) of libxml++ installed.
Here's what I've discovered:

CASE 1) When libxml++ 0.26.0 is installed from an RPM package
packaged by Fedora Linux this is what's installed 

Name        : libxml++                     
Relocations :  (not relocatable)
Version     : 0.26.0                            
Vendor      : Fedora Linux
Release     : 0.fdr.3.rh90                 
Build Date  : Wed 12 Nov 2003 06:23:02 PM EST
Install Date: Thu 05 Aug 2004 11:03:28 PM EDT      
Build Host  : build-rh90
Group       : System Environment/Libraries   
Source RPM  : libxml++-0.26.0-0.fdr.3.rh90.src.rpm

installs these files:

/usr/lib/libxml++-0.1.so.12
/usr/lib/libxml++-0.1.so.12.0.0

Name        : libxml++-devel               
Relocations : (not relocatable)
Version     : 0.26.0                            
Vendor      : Fedora Linux
Release     : 0.fdr.3.rh90                  
Build Date  : Wed 12 Nov 2003 06:23:02  PM EST
Install Date: Thu 05 Aug 2004 11:03:29 PM EDT      
Build Host  : build-rh90
Group       : Development/Libraries         
Source RPM  : libxml++-0.26.0-0.fdr.3. 

installs these files:

/usr/include/libxml++-1.0
/usr/include/libxml++-1.0/libxml++/parsers
/usr/include/libxml++-1.0/libxml++/parsers/domparser.h
/usr/include/libxml++-1.0/libxml++/parsers/parser.h
/usr/include/libxml++-1.0/libxml++/parsers/saxparser.h

/usr/lib/libxml++-0.1.a
/usr/lib/libxml++-0.1.so
/usr/lib/pkgconfig/libxml++-1.0.pc

I have no problem with this installation because I can
get the vitals from 'configure.in' like so:


PKG_CHECK_MODULES(XMLCPP, libxml++-1.0 >= 0.26.0)
AC_SUBST(XMLCPP_CFLAGS)
AC_SUBST(XMLCPP_LIBS)

CASE 2) For non-RPM system, building libxml++-2.6.1 from a tarball:

% ./configure --prefix=/usr && make && make install

/usr/include
/usr/include/libxml++-2.6
/usr/include/libxml++-2.6/libxml++
/usr/include/libxml++-2.6/libxml++/parsers
             ...
/usr/include/libxml++-2.6/libxml++/parsers/parser.h
/usr/lib
/usr/lib/libxml++-2.6.so.1.0.1
/usr/lib/libxml++-2.6.so.1
/usr/lib/libxml++-2.6.so
/usr/lib/libxml++-2.6.la
/usr/lib/libxml++-2.6.a
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libxml++-2.6.pc


CASE 3) For non-RPM system, building libxml++-2.7.0 from a tarball:

% ./configure --prefix=/usr && make && make install

libxml++-2.7.0
==============
                                                                                               
/usr/include
/usr/include/libxml++-2.6
/usr/include/libxml++-2.6/libxml++
/usr/include/libxml++-2.6/libxml++/parsers
/usr/include/libxml++-2.6/libxml++/parsers/parser.h
             ...
/usr/include/libxml++-2.6/libxml++/keepblanks.h
/usr/lib
/usr/lib/libxml++-2.6.so.1.0.2
/usr/lib/libxml++-2.6.so.1
/usr/lib/libxml++-2.6.so
/usr/lib/libxml++-2.6.la
/usr/lib/libxml++-2.6.a
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libxml++-2.6.pc

------------------
DISCUSSION:

It seems that as far as pkg-config tool is concerned, the *.pc
file should have the same name in all 3 cases rather then

case 1 : /usr/lib/pkgconfig/libxml++-1.0.pc
case 2 : /usr/lib/pkgconfig/libxml++-2.6.pc
case 3 : /usr/lib/pkgconfig/libxml++-2.6.pc

Is there a problem with the way case 1 packages the files?
Should then name of PC file be libxml++2.6.pc in all 3 cases?

The installation itself is confusing too:

case 1 : /usr/include/libxml++-1.0
case 2 : /usr/include/libxml++-2.6
case 3 : /usr/include/libxml++-2.6

case 1 : /usr/lib/libxml++-0.1.so
case 2 : /usr/lib/libxml++-2.6.so
case 3 : /usr/lib/libxml++-2.6.so

Looks like there is no version difference between 2.6 and 2.7 ???
But according to http://libxmlplusplus.sourceforge.net/, 2.6 and 2.7
have different APIs but they suppose to work just fine with 
libxml2 >=2.6.1 and glibmm-2.4 >=2.4.0.

BTW, here is the place where I've got RPM from:
http://dag.wieers.com/packages/libxml++/

And this is THE ONLY place where I could get libxml++ RPMs from.
I wouldn't mind building my own RPM from a tarball, but for 
installations without development environment, this is out of
question. I should be able to point my users to some RPM repository
with sane properly built libxml++ RPMs.

Sounds like the RPM is wrong and for all libxml++-2.k.x where k >= 6,
they all should be identified as libxml++-2.6.pc and should
all install in $prefix/include/libxml++-2.6 and so forth.
Conclusively, 'configure.in' should test for:


PKG_CHECK_MODULES(XMLCPP, libxml++-2.6 >= 0.26.0)
AC_SUBST(XMLCPP_CFLAGS)
AC_SUBST(XMLCPP_LIBS)

The only problem I have with this approach is that it doesn't 
mirror libxml2's structure itself (but perhaps it shouldn't):


/usr/lib/libxml2.so.2
/usr/lib/libxml2.so.2.6.8
/usr/lib/libxml2.so

/usr/include/libxml2/libxml
/usr/include/libxml2/libxml/DOCBparser.h
/usr/include/libxml2/libxml/HTMLparser.h
/usr/include/libxml2/libxml/HTMLtree.h
/usr/include/libxml2/libxml/SAX.h
/usr/include/libxml2/libxml/SAX2.h
         ...
/usr/include/libxml2/libxml/xpointer.h

/usr/lib/pkgconfig/libxml-2.0.pc
/usr/lib/xml2Conf.sh
/usr/share/aclocal/libxml.m4

I'd like to hear your comments/suggestions,
-- Vlad
_____________________________________________________________
Vladislav Grinchenko       http://home.comcast.net/~3rdshift/
                                 e-mail: 3rd...@co...
                                                   
      Focus on quality, and productivity will follow.
_____________________________________________________________

Re: [libxml++] regarding libxml++ DTD support

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

On Wed, Aug 04, 2004 at 07:04:18PM +0800, ja...@so... wrote:
> But for SAX parser, how should I make use of DTD ?

  "make use of DTD" means nothing. Be explicit, do you want:
    - DTD validation ?
    - External entity parsing ?
    - Entity substitution ? 
    - etc ...

SAX in libxml2 does not allow DTD validation.
SAX is IMHO a very bad API for 95% of the users. The 5% left 
are better off using the C directly and not binding because it's 
all about speed and crossing languages boundaries for all callbacks
are just not sensible if you're really in need highest performances.

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/

[libxml++] regarding libxml++ DTD support

[<ja...@so...>]

Hi ,

I have the libxml++ version "libxml++-2.6.0.tar.gz"

I am trying out examples in it!

Is there any support for DTD, using SAX parser ?

For DOM parser its there, and its working fine.

But for SAX parser, how should I make use of DTD ?
Does any one having sample code of it ?


Thanks
Jasper

[libxml++] Re: help needed to libxml++

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

Hi,

The linking problem seems related to glibmm/glib. Did you recently 
changed your glib but not glibmm ?

Also, can you use the mailing-list if you need help. Thanks.

Regards,

Christophe


ja...@so... wrote:

>Hi,
>
>I downloaded the libxml++-2.6.0.tar.gz.
>
>I am working on redhat-8
>
>After unpacking the tar, I have done ./configure.
>It went smoothly.
>
>But while doing make, I am getting following error :
>
>make[2]: Entering directory
>`/home/jasper/LIBXML/libxml++-2.6.0/examples/dom_build'
>/bin/sh ../../libtool --mode=link g++  -g -O2   -o example  main.o 
>.../../libxml++/libxml++-2.6.la  -lxml2 -lpthread -lz -lm -lglibmm-2.4
>-lgobject-2.0 -lsigc-2.0 -lglib-2.0
>g++ -g -O2 -o .libs/example main.o  ../../libxml++/.libs/libxml++-2.6.so
>/usr/lib/libxml2.so -lpthread -lz -lm /usr/lib/libglibmm-2.4.so
>-lgmodule-2.0 -ldl -lgobject-2.0 /usr/lib/libsigc-2.0.so -lglib-2.0
>-Wl,--rpath -Wl,/usr/local/lib
>/usr/lib/libglibmm-2.4.so: undefined reference to `g_main_depth'
>/usr/lib/libglibmm-2.4.so: undefined reference to `g_spawn_close_pid'
>collect2: ld returned 1 exit status
>make[2]: *** [example] Error 1
>
>
>Am I doing anything wrong ?
>
>
>Please help,
>
>thanks
>Jasper
>
>  
>

[libxml++] xpaths and namespaces

[Thomas V. <tvo...@gm...>]

Hello,

I'm trying to use XPaths on documents which use namespaces (e.g. 
libxml++-2.6.1/examples/sax_exception/example.xml). My code looks like this:

xmlpp::DomParser dp;
dp.parse_file("example.xml");
xmlpp::Document* doc = dp.get_document();
xmlpp::Element* root = doc->get_root_node();
xmlpp::NodeSet set = root->find("//gjob:Jobs");

If I use "//gjob:Jobs" i get "XPath error : Undefined namespace prefix", 
and "//Jobs" just returns an empty set.
I assume I have to register the namespace first, but I couldn't find 
anything about this in the documentation.

thanks in advance for your help.

Thomas Volpini

RE: [libxml++] Putting values in a decent data structure

[<and...@am...>]

> On Tue, 2004-06-01 at 03:35, Daniel Holbach wrote:
> > I want to read a XML file and stick into a data structure 
> of my own; I

I've played around with using gccxml
and/or SWIG to automatically generate
the code that reads the XML and transfers
the data to the C/C++ struct/class,
and vice versa.

I've demoed it, but have not written a generic
tool yet.  Some of the junior guys in my group
have been using gccxml more and more, at my suggestion.

Here're some notes that may help you if you pursue
this direction:

   * gccxml is "more accurate", because it is based
     on the GCC compiler.  Unfortunately, it requires
     patches to be applied to the compiler, 
     and they are to an older version of GCC that 
     cannot compile some of the C++ code my group generates.

   * SWIG is "nicer" because it does not lose info
     such as #defines.
   * gccxml loses most info about enums.

   * SWIG doesn't understand nested class definitions

Currently, we are emphasizing gccxml because SWIG's
intrinsic limits wrt nested classes, etc., mean that
it cannot handle much of our code.  However, my guess
is that gccxml is going to die out over time; eventually
SWIG will be good enough.

Here's the basic flow:

   * gccxml generates an XML representation of the
     program, in particular the structs/classes.
     Call this datastructure-def.xml.

   * my/your tool takes datastructure-def.xml,
     and generates a C/C++ program that 
     knows how to read from an XML datastructure
     - call this second thing datastructure-value-instance.xml
     - and write to the C/C++ fields.
     Call the code generated by this 
     xml-serializer-Foo.cpp, for class Foo.

   * Now you compile xml-serializer-Foo.cpp,
     link it into your program, and you are off!

You can avoid the code generation step 
by using datastructure-def.xml 
to tell you what offsets and data types to use
- and then doing a lot of raw menmory writes
through void*s or the like.  
I prefer to generate the code because it is 
more portable, less likely to have 
portability problems like BigEndian vs. LittleEndian;
plus, not only is it safer code, but it is also
likely to be faster.

Re: [libxml++] Putting values in a decent data structure

[Dan D. <da...@de...>]

On Tue, 2004-06-01 at 03:35, Daniel Holbach wrote:
> I want to read a XML file and stick into a data structure of my own; I

Did you see the examples/sax_parser_build_dom ?
It shows how to build your own classes derived from xmlpp:Element and to
use the SAX parser to construct an application-specific DOM. Then, all
of the relationship-handling is inherited from xmlpp/libml2's DOM. It
may not be exactly what you want, but it might give you some ideas.

Re: [libxml++] Putting values in a decent data structure

[Jonathan W. <co...@co...>]

On Wed, Jun 02, 2004 at 10:25:04AM +0200, Daniel Holbach wrote:

> Hello Christophe, hello list :-)
> 
> first of all, thanks for your answer.
> 
> Am Di, den 01.06.2004 um 15:44 Uhr +0200 schrieb Christophe de VIENNE:
> > What makes you think it's inappropriate ? As long as your structures and 
> > your xml tree are organised in a similar way, I'd say that using xpath 
> > expressions is a bit overkill.
> Maybe you're right, but i didn't know exactly, how to access all the
> subsequent entries of the <datasource>-tags, I only found the
> find()-method.
> 
> I now organized the data structures in another way, but my problem is
> still the same: it's not easy at all to know when to append a list to
> the aequivalent structure of the father node.

Surely if you see <ccc> after a series of <eee> elements you know that
the <ddd> parent of the <eee>s has been closed and you should append the
list of <eee>s to the parent node, and start parsing the new <ccc>.

If I understand you correctly it's simply a matter of keeping some state
so you know what the previous element was. A simple std::string to hold
the name of the last element seen should be enough.
If the current node is one that appears nearer the root of the document
than the previous node then you know that the previous node and its
parent have been closed.

jon


-- 
"It is always the best policy to tell the truth, unless, of course, you 
 are an exceptionally good liar."
	- Jerome K. Jerome

Re: [libxml++] Putting values in a decent data structure

[Daniel H. <dh...@ma...>]

Hello Christophe, hello list :-)

first of all, thanks for your answer.

Am Di, den 01.06.2004 um 15:44 Uhr +0200 schrieb Christophe de VIENNE:
> What makes you think it's inappropriate ? As long as your structures and 
> your xml tree are organised in a similar way, I'd say that using xpath 
> expressions is a bit overkill.
Maybe you're right, but i didn't know exactly, how to access all the
subsequent entries of the <datasource>-tags, I only found the
find()-method.

I now organized the data structures in another way, but my problem is
still the same: it's not easy at all to know when to append a list to
the aequivalent structure of the father node.

If none of you has an additional hint for me, I'll just try to sort it
out somehow. Passing NodeLists will require a rewrite of the methods.

> Either use the NodeLists, either make more precise xpath expression.
I'll look at the xpath tutorial again.

Thanks again for the advices,
have a nice day,
 Daniel

Re: [libxml++] Proposition: nodes manipulation

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

Christophe de VIENNE wrote:

> That why I want to discuss this API change. I'm not 100% sure it worth 
> it (let's say I'm around 75% :-), but I'm sure it worth a try.
> I think being able to construct a subtree independently from the final 
> tree is interesting.

Definitely, though the way I'v been doing this is by creating a temporary
document that acts as the node factory / garbage collector / etc. and
so the user ever only has to care about deleting all the documents
he's been working on. The rest is managed by the library. That's the
simplest solution (both in terms of semantics as well as API / implementation)
you can get.

Regards,
		Stefan

Re: [libxml++] Proposition: nodes manipulation

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

Stefan Seefeld a écrit :

> Christophe de Vienne wrote:
>
>> Currently, the lifetime of nodes is controlled by libxml2, via 
>> callbacks on node ceation/deletion. The restrictions are that we 
>> cannot create a standalone node, nor detach and then delete a node 
>> like a normal class instance.
>
>
> Why do you believe this is a restriction ? Being able to unlink a node
> from its document will open up a big can of worms. Not only will you
> have to deal with resource allocation issues (until now nodes are owned
> and thus taken care of by a document), but there are other issues such
> as context data that are required for the node to make sense. Just think
> about namespaces.


I see what you mean. In my mind the restriction is compared to what 
libxml2 proposes.
Any issues with context datas are already adressed by libxml2, and 
ressource allocation issues could eventually be solved with smart 
pointers (cf my other post).

>
> Sometimes it's better for an API to make it hard (if not impossible)
> for users to do certain things, just because there are better ways
> to achieve what they want.


That why I want to discuss this API change. I'm not 100% sure it worth 
it (let's say I'm around 75% :-), but I'm sure it worth a try.
I think being able to construct a subtree independently from the final 
tree is interesting.

Regards,

Christophe