libxmlplusplus-general — Open discusions about libXML++

[Libxmlplusplus-general] libxml++ evolution

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

Christophe de VIENNE wrote:

> Stefan, since you're actively partipating to libxml++ now, I can give you 
> access to the CVS for a while. Even if the new concepts you're bringing are 
> not yet production ready, we seems to agree on including them for future 
> releases.

sure, I think that would make things easier for us all. I also agree
with Murray that it is important to respect existing policies.
However, I don't agree that individual checkins must not generate
regressions. Sometimes changes are quite complex, and imply more than
just an implementation fix.
It is, however, crucial that the people collaborating share a common 
vision, and that the ckeckins are aligned with that. For example, the
transition to the new wrapper types I have been proposing requires some
rethinking in terms of the API. I think it's much more easy to make
the transition incrementally, accepting that the code will temporarily
contain regressions, as long as they are well known and tracked.

> One more thing : since C member instance are pointers to structure each time, 
> it would be very easy now to apply the pimpl idiom, which wouldn't be a bad 
> thing I think.

uh, well, I doubt this is a good idea in this case. DOM nodes are very
lightweight, and should remain to be. The more indirections we
introduce, the heavier we get.

Again, my vision of libxml++ is not to present an abstract XML API that
uses late (runtime) binding to map to an implementation. It is a 
specific and lightweight wrapper around libxml2. Performance must be an
issue.

Regards,
		Stefan

[Libxmlplusplus-general] new patch

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

ok, next try:

https://sourceforge.net/tracker/?group_id=12999&atid=312999

contains my patch. I now use _private pointers everywhere,
i.e. for all currently supported node types, attributes, and
even the dtd.
This time it uses libxml2's new callback mechanism for the
memory management (note that you need version 2.5.1 for it to
compile. I didn't touch the configure yet to test for that
version)

As you will see, I cut down redundant methods quite radically.
No offence intended ;-) I dropped all constructors but the
one taking the implementation pointer, as that is the one
being called from the callback. For all other constructors
we have to rethink the memory ownership. I have a couple of
ideas how to get this right, involving factory methods...

Also, I dropped all the 'write' related stuff, as that isn't
needed any more: as now there is only one xml tree, there is
no need to dump the C++ tree into a temporary libxml2 tree
in order to let libxml2 externalize it.

Also, all the node API is really implemented in the Node base
class, just in the protected part, and the individual derived
node types drag the respective methods into the public part,
or map it to better method names.

Finally, there are some methods that I'm not sure whether
and how to implement them, as they don't seem to make
much sense in this context: I'm talking about 'add_child_content'
et al., i.e. where the behavior depends on the (node) types
of the parent and the child types. Since we are talking about
a statically typed API, shouldn't we always know whom we ask
to insert stuff, thus being more explicit like 'add_child'
in elements, and 'add_content' in text nodes. Etc.

As the last time, this doesn't touch the public API, with
one little exception: 'get_content' now returns a string copy,
not a reference. That's just the way it has to work when the
internal representation is something else.

Let me know whether this is accepted, the next patch will be
the 'Document' type, and then the xpath lookup I'v been talking
about. Then it's time for some more unit tests...

Regards,
		Stefan

Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

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

Christophe de VIENNE wrote:

> I'm currently not having the time to do this, but your patches are very 
> welcome. However I won't put them in the current branch but in the unstable 
> one (which does not exists yet but as soon as it is needed, it will) as 
> Murray said.

ok, here is the first patch. The goal was to change the implementation to
delegate whatever we can down to libxml2, while respecting the existing API.

So, everything compiles, and the examples run unchanged.

There are, however, a couple of issues which need to be addressed. I hope we can
sort them out together. First a little account on what this change does:

All libxml2 structures use '_private' members for application data. I use that
to point to the corresponding libxml++ wrapper class, so we can do a reverse
lookup. For example, to access the first child node of a xmlpp::Node object,
you'd do something like:

reinterpret_cast<Node *>(this->_impl->children->_private)

Easy enough, isn't it ?

The tricky point is, as said earlier, ownership management. libxml2's nodes
are owned by their parent nodes (and ultimately by the enclosing document),
not by the libxml++ wrapper object. We need to work out how transfer of ownership
should happen when a node is unlinked from its document / parent node.

Another tricky point is that libxml2 will automagically merge nodes occasionally,
for example if you insert a new text node right after an existing text node.
Thus,

Node *Node::add_child(const std::string &)

may or may not return a new object. It is, however, (and luckily,) owned by the
parent node, so the caller doesn't have to care. A similar argument is to be made
for setting attributes.

All this said, I believe there are now a couple of ways to enhance the API itself:

* I'd like to add iterators to make child node and attribute traversal more efficient
   (right now they are copied into a temporary container that is returned)

* I'd like to suggest to add a 'Visitor' interface for simpler traversal of a document,
   notably to externalize it (the 'write' method would look a *lot* simpler)

* the domparser should be refactored into a 'Document' and possibly a single
   'Document *parse_document(std::istream &)' factory function.

* add new node types such as 'processing instruction', 'cdata section', etc.

* new functionality can be added (notably the xpath lookup stuff I have been suggesting)

* do the split into character type agnostic/specific parts, and hook up external
   unicode libraries

Anyways, I guess that's enough for tonight :-)
Let me know what you think of this plan...

Enjoy,
		Stefan

Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Lundi 27 Janvier 2003 21:47, Stefan Seefeld a =E9crit :
> Christophe de Vienne wrote:
> >>Hope this makes some sense to you.
> >
> > A lot of. But the change you suggest in the way _TextNode would be
> > implemented is big : at this time, the libxml2 types (xmlNode in this
> > case) are used only are read/write time, not to store the datas while
> > manipulating nodes.
>
> exactly, which is (part of) why I suggest in the other thread to use
> xmlNode as the implementation ubiquitously.

I hadn't read this thread then. Now I see better what you meant.

> [...]
> yes, understood. Well, I'll play a bit with an implementation as
> suggested, and then send in more suggestions. Based
> on that we can then discuss whether and how to do the migration.
>
> Sounds good ?
>


Yes. In fact, after reading the other thread, I agree that using xmlNode=20
(libxml) the way you suggest if far better than what's currently done.
One other positive aspect will be that if a user want's to use some libxml2=
=20
method we did not wrap, it will be easily doable.

I'm currently not having the time to do this, but your patches are very=20
welcome. However I won't put them in the current branch but in the unstable=
=20
one (which does not exists yet but as soon as it is needed, it will) as=20
Murray said.

Best regards,

Christophe

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj42U8YACgkQB+sU3TyOQjB3WQCfVfoctputavY0ic7Q7x92hV3x
V1EAn3Ssatl117UJWc2jRlB532pY/eJ2
=3D+Sh3
=2D----END PGP SIGNATURE-----

Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

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

Christophe de Vienne wrote:

>>Hope this makes some sense to you.
>>
> 
> 
> A lot of. But the change you suggest in the way _TextNode would be implemented 
> is big : at this time, the libxml2 types (xmlNode in this case) are used only 
> are read/write time, not to store the datas while manipulating nodes.

exactly, which is (part of) why I suggest in the other thread to use
xmlNode as the implementation ubiquitously.

> But I like much the idea so I see two options :
> - doing exactly the way you did, but this means rethink completely the way 
> Node is implemented
> - Keep the idea of a templated class, but with no parent class, and 
> string_type as the content type.

yes, both would work for the actual issue. But I'd suggest to use
xmlNode for other issues, tue (notably to really delegate whatever we
can down to libxml2, such as xpath lookups).

[snip]

> This way we wouldn't have to modify too much the current implementation, 
> unless we decide that it's better to rely on libxml2 types to store datas.

yes, understood. Well, I'll play a bit with an implementation as
suggested, and then send in more suggestions. Based
on that we can then discuss whether and how to do the migration.

Sounds good ?

Stefan

Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

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

Le Lundi 27 Janvier 2003 20:58, Stefan Seefeld a =E9crit :
> hi there,
>
> libxml2 uses some internal utf8 types to represent characters.
> libxml++ currently uses std::string, which only works for characters
> in the ASCII subset of utf8. It was suggested to use glibmm::ustring
> instead, but I'd like to propose a different solution:
>
<big snip>
>
> Hope this makes some sense to you.
>

A lot of. But the change you suggest in the way _TextNode would be implemen=
ted=20
is big : at this time, the libxml2 types (xmlNode in this case) are used on=
ly=20
are read/write time, not to store the datas while manipulating nodes.

But I like much the idea so I see two options :
=2D doing exactly the way you did, but this means rethink completely the wa=
y=20
Node is implemented
=2D Keep the idea of a templated class, but with no parent class, and=20
string_type as the content type.

template <typename string_type, typename string_traits>
class TextNode
{
public:
   void set_content(const string_type &content)
   {
      _TextNode::set_content(string_traits::to_utf8(content));
   }

   void write(xmlDocPtr doc, xmlNodePtr parent) const;
private:
   string_type content;
};

Then the write() member function would use the string adaptor to produce th=
e=20
libxml2 node.

void TextNode::write(xmlDocPtr doc, xmlNodePtr parent) const
{
  xmlNodePtr node =3D xmlNewText( string_traits::to_utf8(_content) );
/* ... */
}

The read method would do the exact oposite.
This way we wouldn't have to modify too much the current implementation,=20
unless we decide that it's better to rely on libxml2 types to store datas.


Thanks for your suggestion,

Christophe

Re: [Libxmlplusplus-general] XML ns support ?

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

Vladimir Roganov wrote:
> Hello!
> 
> Thanks for xml++ - it is very useful in our projects :-)
> 
> I don't see any XML::namespace support in xml++.
> For example, stylesheet load/save strips all 'xsl:' prefixes.

that may be a problem with your xml document. Did you declare
the namespace correctly ?


Stefan

[Libxmlplusplus-general] parametrizing libxml++ for the character /string type

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

hi there,

libxml2 uses some internal utf8 types to represent characters.
libxml++ currently uses std::string, which only works for characters
in the ASCII subset of utf8. It was suggested to use glibmm::ustring
instead, but I'd like to propose a different solution:

What if the xmlpp::Node class (as an example) is split into two
parts: one that is character type agnostic, i.e. uses libxml2's
internal type, and one that does the conversion to C++ types (for
example glibmm::ustring) ?

Here is how this could look like:

class _TextNode
{
public:
   void set_content(const xmlChar *content)
   {
      xmlNodeSetContent(_impl, content);
   }

   /* ... */
private:
   xmlNode *_impl;
};

template <typename string_type, typename string_traits>
class TextNode : private _TextNode
{
public:
   void set_content(const string_type &content)
   {
      _TextNode::set_content(string_traits::to_utf8(content));
   }
   /* ... */
};

So, the real libxml2 wrapper class for a text node is _TextNode.
It's this class that does all the real work. TextNode then provides
a thin Adapter to that (i.e. it uses _TextNode as implementation)
providing a type-safe interface, and by means of the 'string_traits'
providing a mapping to arbitrary user-provided unicode implementations.

You may just do a

typedef TextNode<glibmm::ustring, your_ustring_adaptor> YourTextNode;

to hide the templating, while others can use a different unicode
library.

Hope this makes some sense to you.

Stefan

[Libxmlplusplus-general] compilation problems

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

hi,

after checking out libxml++ from cvs, I run
./autogen.sh.

That generates the error:

aclocal: configure.in: 36: macro `AM_PROG_LIBTOOL' not found in library

Having never used automake or libtool in my own
projects before, I don't really know what the problem is
or how to fix it. I'm running RH 8.0, in case that matters
(automake version 1.7, libtool version 1.4.2)...

Thanks,
		Stefan

[Libxmlplusplus-general] XML ns support ?

[Vladimir R. <va...@sk...>]

Hello!

Thanks for xml++ - it is very useful in our projects :-)

I don't see any XML::namespace support in xml++.
For example, stylesheet load/save strips all 'xsl:' prefixes.

I missed something in headers/sources/documentation ?   
Or it's really unimplemented ?  (if so, Your advices - ) ? 

-- 
Best regards,
Vladimir

[Libxmlplusplus-general] TextReader class

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

The recent flurry of activity on this list has reminded me that I
prepared a simple C++ wrapper for the new xmlTextReader interface in
libxml, described here: http://xmlsoft.org/xmlreader.html

I'm sure it's incomplet and inkorrekt, but would you guys be interested
in seeing it? You'd be free to include it in libxml++ if you wished
(with whatever changes are necessary to make it work properly!)

jon


-- 
"Anybody who hates dogs and loves whiskey can't be all bad."
	- W.C. Fields

Re: [Libxmlplusplus-general] API stability

[Rolf D. <dub...@pk...>]

On Friday 24 January 2003 11:49 am, Christophe de VIENNE wrote:
> Yes there will be a 1.0. It should have the 0.18.0 API (debugged if
> needed), unless bugs force us to change it.

Great. Thanx a lot. I am using 0.18.0 for some very simple things since it 
came out and have no problems with it.

Thanx,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rol...@Ph...
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************

Re: [Libxmlplusplus-general] API stability

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Vendredi 24 Janvier 2003 11:35, Rolf Dubitzky a =E9crit :
> Hi,

Hi,

>
> will there be a 1.0 in the near future? If not, is 0.18.0 concidered to be
> at least 'almost' API stable, or are there many/major changes planed till
> 1.0?

Yes there will be a 1.0. It should have the 0.18.0 API (debugged if needed)=
,=20
unless bugs force us to change it.
We had no bugreport on 0.18.0 since it's release, so I think that by the=20
beginning of febuary I will release it under 1.0.0, and consider it a API=20
stable.

=46urther enhancements will be done on a new branch, probably 1.1.


Best regards,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj4xGiIACgkQB+sU3TyOQjBmwQCePKeaDjiHSPeC42prXYGjWAiX
0JwAoLgoLWszQ7rV8jESXtPuezN0cFUl
=3Dwc+E
=2D----END PGP SIGNATURE-----

[Libxmlplusplus-general] API stability

[Rolf D. <dub...@pk...>]

Hi,

will there be a 1.0 in the near future? If not, is 0.18.0 concidered to be at 
least 'almost' API stable, or are there many/major changes planed till 1.0?

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rol...@Ph...
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************

[Libxmlplusplus-general] API questions

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

hi there,

I'm currently looking into existing C++ wrappers
for libxml2. I'v written one myself, as a Quick Hack (tm),
but would like to get rid of that and rather contribute
to an existing one and focus on the stuff I'd actually do
with that library...

One thing I do a lot right now with xml documents is reading
them in (DOM), then searching for specific data. I do this
with xpath expressions, so I need a way to retrieve a 'NodeSet'
from a document, given an xpath.

What is needed for this is 1) a document to search in, 2) a
context node, 3) the actual xpath expression.

Would you be interested into a patch that adds
such functionality ?
You currently don't have a 'Document' class (though the
'DomParser' comes close), and the 'Node' class doesn't
know the document it is part of.

The simplest change would be an added 'lookup' method in
the DomParser:

typedef std::vector<Node *> NodeSet; // pointers or deep copies ?

NodeSet DomParser::lookup(const Node *context,
                           const std::string &xpath) const;

Though there are a couple of 'issues':

1) I really think I'm not searching in a parser, but in a
    document (a DOM tree, actually), though it's the DomParser
    that creates it (factory).

2) For various reasons I think nodes should hold a reference to
    the document they are part of. This is important as soon as
    you want to interpret them, for example namespaces can only
    looked up in the document, the same is true for default attributes
    (defined in the dtd).
    Assuming the node knows its document, the above 'lookup' method
    could be written more naturally as

    'NodeSet Node::lookup(const std::string &) const;'

Another question I have is about the supported character domain.
You currently use std::string, but it is obvious that this isn't
enough, at least not if you want to provide a generic XML API.
I read in a message about using glibmm. What's the background for
this ? What functionality do you need from there ? Why wouldn't
a simple replacement of std::string by std::wstring suffice ? The
actual unicode processing isn't the scope of libxml++, or is it ?

Looking forward to using libxml++ in my future work,

kind regards,
		Stefan

[Libxmlplusplus-general] Libxml++-0.18 announce

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

You can download the new version of libxml++-0.18.
https://sourceforge.net/project/showfiles.php?group_id=12999&release_id=132559

Notes:
This release comes with a major API change in nodes. The API should be 
stabilised to this for the 1.0 version, unless we have some bugs which force 
us to change it. 

Changes:
* big API change for nodes handling : the different types of node now herit 
from a base Node class. This, among other advantages, avoids previous 
ambiguity on content() acessors meaning.
* little bugfixes and improvements in SaxParser.


Best Regards,

Christophe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj4dWJoACgkQB+sU3TyOQjCFWQCg1hMdwY8Y/HN7dcRs/QmBfeOB
kZEAoJYbz+vUqb4oWijFTnhA4ZW+nBeD
=woz4
-----END PGP SIGNATURE-----

[Libxmlplusplus-general] Re: libxml++ 0.17

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

Le Lundi 30 D=E9cembre 2002 01:19, vous avez =E9crit :
> Hi,

Hi,

> Do you have a larger example how to create a DOM model in memory,
> using the library API?

no

> [...]
> What are the future plans for libxml++ and what is
> the roadmap towards an 1.0 release?

There is no precise roadmap for now.
future plans are : rethink Node API (almost done), add per-parser options, =
add=20
validation, probably add xpath support.

Cheers,

Christophe

[Libxmlplusplus-general] How to get Attributes from a Node?

[Jone M. V. <jmv...@br...>]

After upgrading to 0.1.7 it seems that the only way to get hold of the 
Attributes of a Node is by creating a new Node. Is this correct?
Have a nice day!
Jone Marius Vignes

Re: [Libxmlplusplus-general] DomParser behaviour

[Jone M. V. <jmv...@br...>]

On Thursday 02 January 2003 22:28, Christophe de Vienne wrote:
> Le Jeudi 2 Janvier 2003 21:44, Jone Marius Vignes a écrit :
> > When calling parse_memory with the following string:
>
> [...]
>
> Hi Jone,
>
> Which version of libxml++ are you using ? This issue shouldn't happen in
> 0.17.

Ok, that's the problem (debian sid is still on 0.16). Thanks!
BLiP!

> Cheers,
>
> Christophe
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general

Re: [Libxmlplusplus-general] DomParser behaviour

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

Le Jeudi 2 Janvier 2003 21:44, Jone Marius Vignes a =E9crit :
> When calling parse_memory with the following string:
[...]

Hi Jone,

Which version of libxml++ are you using ? This issue shouldn't happen in 0.=
17.

Cheers,

Christophe

[Libxmlplusplus-general] DomParser behaviour

[Jone M. V. <jmv...@br...>]

When calling parse_memory with the following string:
<?xml version="1.0"?>
<methodCall>
<methodName>methodname</methodName>
	<params>
		<param>
			<value>
				<struct>
					<member>
						<name>test</name>
						<value><int>4</int></value>
					</member>
					<member>
						<name>test2</name>
						<value><int>4</int></value>
					</member>
				</struct>
			</value>
		</param>
	</params>
</methodCall>

...I get the following from the parser:
<?xml version="1.0"?>
<methodCall>
	<methodName>
		<text>methodname</text>
	</methodName>
		<params>
			<param>
				<value>
					<struct>
						<member>
							<name><text>test</text></name>
							<value><int><text>4</text></int></value>
						</member>
						<member>
							<name><text>test2</text></name>
							<value><int><text>4</text></int></value>
						</member>
					</struct>
				</value>
			</param>
		</params>
</methodCall>

As you can see, every content of the original xml-string is put into a 
<text></text> tag. Is this intended, and if it is, why?

Have a nice day!
Jone Marius Vignes

Re: [Libxmlplusplus-general] Bug in SaxParser::parse_stream?

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks !

The patch has been included in the CVS.

If you ever have other patchs to propose, please use the patch tracker on=20
sourceforge and update the Changelog too.

Cheers,

Christophe



Le Mercredi 18 D=E9cembre 2002 10:35, Fredrik Arnerup a =E9crit :
> Hello,
>
> I think I have found a bug in SaxParser::parse_stream (saxparser.cc)
> in libxml++ 0.17.0. This code:
>
>   if( ! _exception )
>   {
>     exception * tmp =3D _exception;
>     _exception =3D 0;
>     tmp->Raise();
>   }
>
> will either do nothing at all or try to follow a null pointer.
>
> Below is a patch for what I think was intended.
>
> /Fredrik Arnerup
> e97_far@e.kth.se
>
> --- libxml++-0.17.0/libxml++/parsers/saxparser.cc	Mon Dec  9 20:35:33 2002
> +++ ../libxml++-0.17.0/libxml++/parsers/saxparser.cc	Wed Dec 18 02:04:58
> 2002 @@ -175,11 +175,11 @@
>      xmlParseChunk(_context, NULL, 0, 1);
>
>    xmlFreeParserCtxt(_context);
>    _context =3D NULL;
>
> -  if( ! _exception )
> +  if( _exception )
>    {
>      exception * tmp =3D _exception;
>      _exception =3D 0;
>      tmp->Raise();
>    }
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj4AUmMACgkQB+sU3TyOQjCLTQCgwNzabvTlxX16jEcmdFdzYdCB
otwAoLIzzT5Rw6P5XtLYYdS42Z8w9/Fx
=3DQx6L
=2D----END PGP SIGNATURE-----

[Libxmlplusplus-general] Bug in SaxParser::parse_stream?

[Fredrik A. <e97_far@e.kth.se>]

Hello,

I think I have found a bug in SaxParser::parse_stream (saxparser.cc)
in libxml++ 0.17.0. This code:

  if( ! _exception )
  {
    exception * tmp = _exception;
    _exception = 0;
    tmp->Raise();
  }
  
will either do nothing at all or try to follow a null pointer.

Below is a patch for what I think was intended.

/Fredrik Arnerup
e97_far@e.kth.se

--- libxml++-0.17.0/libxml++/parsers/saxparser.cc	Mon Dec  9 20:35:33 2002
+++ ../libxml++-0.17.0/libxml++/parsers/saxparser.cc	Wed Dec 18 02:04:58 2002
@@ -175,11 +175,11 @@
     xmlParseChunk(_context, NULL, 0, 1);
 
   xmlFreeParserCtxt(_context);
   _context = NULL;
 
-  if( ! _exception )
+  if( _exception )
   {
     exception * tmp = _exception;
     _exception = 0;
     tmp->Raise();
   }

Re: [Libxmlplusplus-general] newbie question: libxml++ vs. xerces-C++

[Ed H. <ed...@eh...>]

Hi Murray and Christophe,

Thank you for the quick responses!

I think I'll proceed with libxml++ for my project since I like the clean
interface and don't really need UTF8 (yet).  I would love to see DTD
validation added to libxml++ and would be happy to help out (testing,
coding, whatever) with it.

thanks again,
Ed

--=20
Edward H. Hill III, PhD=20
Post-Doctoral Researcher   |  Email:  ed...@eh...,  eh...@mi...
Division of ESE            |  URLs:   http://www.eh3.com
Colorado School of Mines   |    http://cesep.mines.edu/people/hill.htm
Golden, CO  80401          |  Phones:  303-384-2094, 303-273-3483

Re: [Libxmlplusplus-general] Re: newbie question: libxml++ vs. xerces-C++

[darco <da...@de...>]

I believe that transparent support for std::string is built into 
Glib::ustring... So that internaly, libxml++ could use Glib::ustring 
everywhere, and it would implicitly cast to std::string wherever you 
choose to use it.

That's how I understand it anyway...

On Tuesday, December 17, 2002, at 05:22 PM, Greg S. wrote:

> Just to make sure...
>
> When you talk about switching to Glib::ustring in libxml++, you
> *are* planning to do it in such a way that one can still use
> std::string if they require no unicode support, correct?
>
> Thanks,
>
> Greg
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
>
>
--- darco
http://www.deepdarc.com/