libxmlplusplus-general — Open discusions about libXML++

Re: [libxml++] writing formatted (indented) files

[Eric B. <er...@co...>]

On Thu, 2003-05-08 at 11:26, Christophe de Vienne wrote:
> > Daniel would probably tell you in strong terms that formatting is
> > significant therefore libxml shouldn't do it. Some formatting is not
> > significant though, I think.
> 
> Significant no, but very usefull yes. If one have to read the xml file it will 
> be a *lot* easier.

I have to agree with Christophe here - I end up perusing a lot of xml
files by hand, and they are much easier to read when indented than not.
While I realise that this is not strictly part of the specification,
perhaps another member function such as
Document::write_formatted_to_file would be useful for those of us who
would like it. I can also understand Murray's hesitation to add "broken"
things to libxml++.

Cheers,

Eric

Re: [libxml++] writing formatted (indented) files

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

Le Jeudi 8 Mai 2003 14:13, Christophe de Vienne a =E9crit :
> So we could call it in Document::Init::Init() and remove it everywere els=
e.

I've done that and it's working well.
Since the behavior is more consistent like this I'll commit the patch in a =
few=20
minutes.

Should we elaborate something more sophisticated so the user can choose wet=
her=20
the files has to be formatted of not ? I'm not sure it will be a frequent=20
need, and if it's really the case, xmlKeepBlanksDefault(1) could still be=20
called directly if such a need comes.

Regards,

Christophe

Re: [libxml++] Blunt Q: what C++ bindings for XML?

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

and...@am... wrote:

> Common misconception: parsers drop the original text.
> An artifact of the early lexers, like lex.
> 
> Much recent work, e.g. in error handling and macro processing
> and refactoring, has provided access to the original text
> even in the parsed stream.

the question to ask is what content has semantic value. Are
linebreaks, whitespace, etc. to be preserved ?

These questions boil down to what level you are operating on.
Are you interested into the infosets, or do you want to know
the details of how things are encoded in a file ?
As Murray suggests, we are talking about XML here, which is at
least one level on top of raw file data. For example a DTD may
implicitly declare an attribute value for a node, even though
the attribute was not present in the 'raw' input. When looking
at the DOM, you won't see that. That's a feature, not a bug.

If you want to have access to lower levels, use lower levels,
i.e. raw I/O.

> E.g. consider error handling...  it should be possible
> to trace any error back to any and all files, lines, characters
> which are associated with the error. In the presence of macros,
> you should be able to say where the error occurred,
> in every phase of macro expansion.  Yet most parsers that
> drop the original text lose this ability.

well, no. The question is what error we are talking about. Is
it a syntax error that makes the file content invalid XML ?
The XML parser can clearly catch that and report it to you.
If we are talking about structural errors such as a document
that doesn't validate against a dtd/schema, that, too can be
done in a generic way, i.e. by telling the parser to match
the document against a known dtd/schema.
Everything else is up to the application.

Stefan

[libxml++] writing formatted (indented) files

[Eric B. <er...@co...>]

Is there a way to write a formatted file using Document::write_to_file()
in libxml++?

Cheers,

Eric

RE: [libxml++] Patch for Node::find( nonexistent_xpath ) to retur n empty NodeSe t

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

> Anyway, that won't work for patches. We need the ChangeLog 
> entries in order
> to understand the patches and to be sure that a suitable 
> ChangeLog entry
> would be applied when the rest of the patch was applied.

Hey, I'll do it in the future.
ChangeLogs are just not part of my normal development
methodology.  For that matter, neither are patches,
since I normally use CVS.

(No, I'm not asking for CVS here; can't use it, since 
my employer's firewall doesn't let CVS or SSH across it
(at least, not without me doing something improper like
tunnelling across http))

RE: [libxml++] Patch for Node::find( nonexistent_xpath ) to retur n empty NodeSe t

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

> xerces doesn't have an API for xpaths as far as I can see.

Xerces-J (Java) has an XPath module.
I haven't looked in detail.
In general, XML happens first for Java,
tythen for Python/Perl/etc.,
then for C, last for C++.

There's an Open Source add-on for Xerces-C
for XPath, http://software.decisionsoft.com/
Again, haven't tried it. Tastes iffy.

RE: [libxml++] Blunt Q: what C++ bindings for XML?

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

> I don't really understand this. All XML parsers allow you to 
> read the tag
> names and attributes values. But they won't give you the raw 
> text, because
> they are XML _parsers_. You shouldn't need the raw contents and if you
> really think you do then you should use normal file I/O.


Common misconception: parsers drop the original text.
An artifact of the early lexers, like lex.

Much recent work, e.g. in error handling and macro processing
and refactoring, has provided access to the original text
even in the parsed stream.

E.g. consider error handling...  it should be possible
to trace any error back to any and all files, lines, characters
which are associated with the error. In the presence of macros,
you should be able to say where the error occurred,
in every phase of macro expansion.  Yet most parsers that
drop the original text lose this ability.

E.g. consider an XML-like tool.  Consider 

	<foo>
      <bar><blick attr2="3"
                  attr1="4">biff</blick><bar>
      </foo>

Say I want to indent this. But not to the
fully indented form typical of most XML printers:

	<foo>
        <bar>
           <blick attr1="4" attr2="3">
              biff
           </blick>
        </bar>
      </foo>

Instead, I want to indent, but not adding any new newlines,
in either the text or the tags/attributes:

	<foo>
        <bar><blick attr2="3"
                    attr1="4">biff</blick><bar>
      </foo>

The blick indentation seems to require knowledge of the raw
text.

Prettyprinters for programming languages do this - I have coded
them - by *PARSING* that gives significance to whitespace.

I'm looking for such a tool for XML.

Re: [libxml++] Blunt Q: what C++ bindings for XML?

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

and...@am... wrote:

> I haven't looked seriously at any other C++
> bindings for XML.  

while I contributed a bit to libxml++ some months ago,
I then decided to run my own for a variety of reasons.

The most important additional feature over libxml++
I have (well, I consider it a feature :-) is that the
unicode support is parametrized, i.e. all the classes
are templates which you can bind to your preferred
unicode lib via typedefs (we discussed this at length
earler here).

Other differences are for example better support of
xpath (by using an 'XPathResult'), better C++ integration
(iterators, etc.), and so on.

If there is interest I could put the stuff online...

Regards,
		Stefan

RE: [libxml++] Patch for Node::find( nonexistent_xpath ) to retur n empty NodeSe t

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

> > Re ChangeLogs - I'm one of those people whose ChangeLogs
> > get generated automatically from CVS checkins.
> > I suppose I just have to get back into the old
> > fashioned way.
> 
> Well this way, we just have to copy the ChangeLog entry as 
> cvs log message 
> when we commit it in a patch.

I use cvs2cl.pl, and have the ChangeLog generated from
the CVS log entries.  

But I admit that sometimes you want to ChangeLog
to be less verbose than the cvs checkin entries.

Re: [libxml++] Patch for Node::find( nonexistent_xpath ) to retur n empty NodeSe t

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

Le Mardi 6 Mai 2003 22:28, and...@am... a =E9crit :
> > Next time please patch the ChangeLog too and use the patch manager on
> > sourceforge.
>
> Sorry. Out of practice.
>

No problem :-)

> Re ChangeLogs - I'm one of those people whose ChangeLogs
> get generated automatically from CVS checkins.
> I suppose I just have to get back into the old
> fashioned way.

Well this way, we just have to copy the ChangeLog entry as cvs log message=
=20
when we commit it in a patch.


Your patch is in the cvs.

Thanks,

Christophe

RE: [libxml++] Patch for Node::find( nonexistent_xpath ) to retur n empty NodeSe t

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

> Next time please patch the ChangeLog too and use the patch manager on 
> sourceforge.

Sorry. Out of practice.

Re ChangeLogs - I'm one of those people whose ChangeLogs
get generated automatically from CVS checkins.
I suppose I just have to get back into the old 
fashioned way.

Re: [libxml++] Patch for Node::find( nonexistent_xpath ) to return empty NodeSe t

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

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

Le Mardi 6 Mai 2003 19:17, and...@am... a =E9crit :
> Patch attached.  Unidiff -u 20, prepared from cvs diff in my local
> repository.  My version of patch doesn't seem to be
> able to figure out file to patch automatically, but there's only
> one... libxml++/nodes/nodes.c
>
> I chose the fix that most quickly solved my problem:
> having libxml++ return an empty NodeSet when libxml2 does.
> I did NOT choose to throw an exception as Murray suggested,
> since (1) that would make my code using it more complex,
> and (2) it is onconsistent with libxml2.
>

The patch looks good to me. I'll include when I'm home this evening.

Next time please patch the ChangeLog too and use the patch manager on=20
sourceforge.

> Long term the right way is to do what Stefan Seefeld suggested,
> returning an XPathResult that unifies NodeSets and other
> xpath return types.

yes

Thanks,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+t/MtB+sU3TyOQjARAqK5AJ9+2gXFIVoRsttmZEBCZVZUYUPllgCdHWT6
W4lyNgpSoL114iWOCiz1knY=3D
=3DVv9r
=2D----END PGP SIGNATURE-----

[libxml++] Patch for Node::find( nonexistent_xpath ) to return empty NodeSe t

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

> > From: and...@am... [mailto:and...@am...]  
> > Q: what should Node::find( nonexistent_xpath )
> > return if it is called with an xpath that does not exist?
> > 
> > libxml2 returns 0 xmlXPathEval ...
> > which is the "inside" of Node::find(),
> > but Node::find() core dumps.
> 
> That's not good.
> 
> > I.e. libxml2 is better behaved that libxmlpp::find()
> > in this regard.
> > 
> > I strongly suspect that libxmlpp should return an empty set.
> 
> I guess it should throw an expection. A patch would be very welcome.


Patch attached.  Unidiff -u 20, prepared from cvs diff in my local 
repository.  My version of patch doesn't seem to be
able to figure out file to patch automatically, but there's only
one... libxml++/nodes/nodes.c

I chose the fix that most quickly solved my problem:
having libxml++ return an empty NodeSet when libxml2 does.
I did NOT choose to throw an exception as Murray suggested,
since (1) that would make my code using it more complex,
and (2) it is onconsistent with libxml2.

Long term the right way is to do what Stefan Seefeld suggested,
returning an XPathResult that unifies NodeSets and other 
xpath return types.  I'm not bothering to do that yet,
since I have not decided whether to use libxml++ 
or Xerces or xml4c, the IBM C++ binding.

I owe a few more patches, but am reluctant to do so 
until there is a testing framework for libxml++.
Does one of the developers (Murray?) have a preference 
for a testing framework?

[libxml++] Blunt Q: what C++ bindings for XML?

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

Blunt question:  does anyone have
any recommendations for C++ bindings
for XML manipulation?

I chose libxml++ because

(1) the libxml2 webpages at xmlsoft.org
    said libxml++ looked like the most active
    C++ bindings for XML / C++ wrapper around 
    libxml2

(2) Apache Xerces did npt have xpath support;
    pathalan provides Xerces spath support,
    but I thought one-stop shoppig would be good
    
I haven't looked seriously at any other C++
bindings for XML.  

Does anyone have any recommendations?

===

I'm still at the point where I am thrashing
about as to what language to do my XML work in.
Most will be in a scripting language like Perl
or Python; I need minimal support in the native
language for the simulators I write, C++.
I don't need DTD support or the like in C++;
pretty much all I really need in C++ is xpath.

And, I'd *like* something I haven't seen any XML
package in any language support: the ability to
record the raw text, not only of the text, but also
of the tags and attributes.

RE: [libxml++] libxmlpp::DomParser not safe in lists by value - p robably not a v alue type

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

> Yes, could you give us a patch for that? Maybe you should 
> look at the other
> classes too.

Good, glad I asked before trying to fix.

Re: [libxml++] Node::find( nonexistent_xpath )

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

Hi Andy,

as the code you are stumbling over is mine, I'd like
to respond, even if I'm not involved in libxml++ development.

and...@am... wrote:
> Q: what should Node::find( nonexistent_xpath )
> return if it is called with an xpath that does not exist?

Well, the short answer is it should return an (empty)
nodeset. The long answer is that xpath can look up more than
nodes, so the 'find' should return something that wraps among
others a nodeset. Further, the way libxml2 is written means
that 'namespace nodes' are created temporarily in the context
of an xpath lookup (try '*/namespace-uri(.)'], and as soon as
the 'xpath object' is deleted, these nodes are gone.
That implies that the xpath object has to either outlive the
nodeset (for the nodeset to contain valid references), or that
we have to copy the namespace nodes, instead of referencing them.

In my own libxml2 wrapper I thus use a wrapper object 'XPathResult'
that is a logical union of the possible return types of an xpath
search.

Anyways, just some thoughts in case someone wants to work on
libxml++...

Regards,
		Stefan

[libxml++] Node::find( nonexistent_xpath )

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

Q: what should Node::find( nonexistent_xpath )
return if it is called with an xpath that does not exist?

libxml2 returns 0 xmlXPathEval ...
which is the "inside" of Node::find(),
but Node::find() core dumps.

I.e. libxml2 is better behaved that libxmlpp::find()
in this regard.

I strongly suspect that libxmlpp should return an empty set.

RE: [libxml++] libxmlpp::DomParser not safe in lists by value - p robably not a v alue type

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

Sorry... I know I should go and fix it,
but I'll just report the bug and work around it...

[libxml++] libxmlpp::DomParser not safe in lists by value - probably not a v alue type

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

The following code fails, with a segment fault,
on LINUX, g++3.2.1, yada yada yada.

	using namespace std;
	#include <libxml++/libxml++.h>
	int
	main(int argc, char** argv)
	{
  		list<xmlpp::DomParser> lst;
  		lst.push_back( xmlpp::DomParser() );
  		lst.push_back( xmlpp::DomParser() );
	}

The pointer version works:

	using namespace std;
	#include <libxml++/libxml++.h>
	int
	main(int argc, char** argv)
	{
  		list<xmlpp::DomParser*> lst;
  		lst.push_back( new xmlpp::DomParser() );
  		lst.push_back( new xmlpp::DomParser() );
	}

This is almost 100% likely to occur because xmlpp::DomParser
is not a value type - it is not supposed to be copied as
a value.

(I'm reporting this bug before I try a fix, just in case
I get sidetracked into something else.)

Now, I'm not sure whether this is intentional or not.
But I cannot see any reason why it should be.
And I come from the school that says, if you don't
want something to be treated like a first class value object,
then remove (make private) the copy constructor and assignment 
methods.

Code inspection reveals that DomParser has a _doc pointer
member, which could be released twice after a copy.
There's no reference counter or the like on the pointed
to document, or it's _impl.

Anyway, that's enough code review for the initial bug report.
I'll go look for the proper fix, but I'd appreciate email
telling me whether xmlpp::DomParser should be treatable as a value,
with copy constructors, etc., or whether it should be handled
always via pointers.  That's a style question, and y'all own 
the library.

By the way, if you agree with me, that values are a good thing,
then the little test snippet above is something that can be applied
to any value type that has a default constructor.
Make it into a template

    template<typename T> test_push_value() {
  		list<T> lst;
  		lst.push_back( T() );
  		lst.push_back( T() );
    }

(and arrange for it to be called from your test suite).

this sort of thing is such a basic test
(along with its cousins, that test things like
basic constructors) 
and they catch a surprisingly large number of bugs.

[libxml++] xmlpp::Document::write_to_file non const

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

Having xmlpp::Document::write_to_file and write_to_string
not be const is rather surprising.  Is there a reason,
or is it just the usual const-ipation?

Re: [libxml++] memory leak in SaxParser

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

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

Le Jeudi 24 Avril 2003 09:56, thierry a =E9crit :
> as it is done in xmlSAXUserParseMemory...

yes.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+p+yPB+sU3TyOQjARAkMfAJ0VOs0IOGcUSrm/ttAftq6TDPtLGwCdFBuI
iR6XX4Wa+zd+uYDT0HkeAp8=3D
=3DV31n
=2D----END PGP SIGNATURE-----

Re: [libxml++] memory leak in SaxParser

[thierry <thi...@di...>]

at it is done in xmlSAXUserParseMemory...

I think this is the best solution.
Thank you for your immediate reaction.
Good luck


Thierry


----- Original Message -----
From: "Christophe de Vienne" <cde...@al...>
To: <lib...@li...>
Sent: Thursday, April 24, 2003 1:13 AM
Subject: Re: [libxml++] memory leak in SaxParser


Le Mercredi 23 Avril 2003 19:03, Christophe de VIENNE a écrit :
> In fact the good solution is probably to use xmlSAXUserParseFile and
> xmlSAXUserParseMemory to create the contexts, and not
> xmlCreateMemoryParserCtxt and xmlCreateFileParserCtxt which are to be used
> only for DOM.

It seems I've spoken a bit fast sorry ;-) We can't do that. The functions I
spoke about don't return a context.

So we have to make sure either the sax handler can be freed by libxml,
either
handle it ourselves.
The proposed solution was not handling the same problem happening with
xmlCreatePushParserCtxt, that we use for parse_chunk and parse_stream, which
makes a copy of the sax handle we give to it, and this copy is never
released.
So I removed the reset of sax handler in release_underlying. In parse, I
just
save the defaut sax parser and restore after parsing, as it is done in
xmlCreateMemoryParserCtxt for example.

I think this correct the problem(s).

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: [libxml++] memory leak in SaxParser

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

Le Mercredi 23 Avril 2003 19:03, Christophe de VIENNE a =E9crit :
> In fact the good solution is probably to use xmlSAXUserParseFile and
> xmlSAXUserParseMemory to create the contexts, and not
> xmlCreateMemoryParserCtxt and xmlCreateFileParserCtxt which are to be used
> only for DOM.

It seems I've spoken a bit fast sorry ;-) We can't do that. The functions I=
=20
spoke about don't return a context.

So we have to make sure either the sax handler can be freed by libxml, eith=
er=20
handle it ourselves.
The proposed solution was not handling the same problem happening with=20
xmlCreatePushParserCtxt, that we use for parse_chunk and parse_stream, whic=
h=20
makes a copy of the sax handle we give to it, and this copy is never=20
released.
So I removed the reset of sax handler in release_underlying. In parse, I ju=
st=20
save the defaut sax parser and restore after parsing, as it is done in=20
xmlCreateMemoryParserCtxt for example.

I think this correct the problem(s).

Cheers,

Christophe

Re: [libxml++] memory leak in SaxParser

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

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

Le Mercredi 23 Avril 2003 18:04, thierry a =E9crit :
> I have encountered a memory leak (not signalized by Purify) in the class
> SaxParser. in the function parse() :
>
> "_context->sax =3D & _sax_handler;
>
> [..]
>
> release_underlying();"
>
> is not valid. structure allocated in xmlCreateMemoryParserCtxt for the sax
> handler is never released due to
>
> "_context->sax =3D 0 " in release_underlying().
>


Thanks for reporting this problem.

In fact the good solution is probably to use xmlSAXUserParseFile and=20
xmlSAXUserParseMemory to create the contexts, and not=20
xmlCreateMemoryParserCtxt and xmlCreateFileParserCtxt which are to be used=
=20
only for DOM.

I'll commit a patch by the evening.


Best regards,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+psdLB+sU3TyOQjARAkp2AJ9gnVSX/K/WP8R/SVH2y7YHRot7fwCgt5rY
7oTxeM09/oC9XgOpsHrTt00=3D
=3Dko17
=2D----END PGP SIGNATURE-----

[libxml++] memory leak in SaxParser

[thierry <thi...@di...>]

I have encountered a memory leak (not signalized by Purify) in the class =
SaxParser.
in the function parse() :

"_context->sax =3D & _sax_handler;

[..]

release_underlying();"

is not valid. structure allocated in xmlCreateMemoryParserCtxt for the =
sax handler is never released due to=20

"_context->sax =3D 0 " in release_underlying().

The solution I have found was to use memcpy and to really release sax =
object of context.

I don't how to make patch so this is how looks my corrections in parse

void SaxParser::parse(){

if(!_context) throw internal_error("Parse context not created.");

//_context->sax =3D & _sax_handler;

memcpy(_context->sax, &_sax_handler, sizeof(xmlSAXHandler));

_context->userData =3D this;

initialize_context();


xmlParseDocument(_context);

if( (! _context->wellFormed)

&& (! _exception) )

_exception =3D new parse_error("Document not well-formed");

//release_underlying();

xmlFreeParserCtxt(_context);

_context =3D 0;

check_for_exception();

}

best regards

Thierry Blanchard