libxmlplusplus-general — Open discusions about libXML++

RE: [libxml++] node iterators

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

> One problem I faced is the type return by iterator::operator*().
> I first wanted to return a Node &. It is, I think, more 
> logical, and avoid 
> writing things like (*iter)->do_something().
> However this change the use of dynamic_cast to 'test' the 
> type of node. If the 
> cast fail we have an exception instead of just returning a 
> null pointer.
> 
> So the question is :
> What do you expect as a return type for 
> Node::ChildrenList::iterator::operator*() ?

I always use Node& for such code.  (In more detail,
I use a T& if the value is copied into the container,
and if modifying the value in the container does not
affect the value copied from; I use T* if modifying
the value 

To get a non-trapping dynamic cast, the user can always
take the address:

	dynamic_cast<Special_Node*>(&(*iter))

RE: [libxml++] node iterators

[<Mur...@Co...>]

> From: Christophe de VIENNE [mailto:cde...@al...]=20
> Le Vendredi 23 Mai 2003 18:57, and...@am... a =E9crit :
> >
> > In other words, I am agreeing with Murray that it is a separate
> > class.
>=20
>=20
> Me too (that's what I'm saying in the part of the message you=20
> didn't quote :-)
>=20
> So I started implementing something this way. I have the=20
> following classes :
> ChildrenList, ChildrenList::iterator and ChildrenList::const_iterator
>=20
> The API is STL-like :
>=20
> iterator       ChildrenList::begin();
> const_iterator ChildrenList::begin() const;
> iterator       ChildrenList::end();
> const_iterator ChildrenList::end() const;
>=20
> on the different iterators we have operators ++(), ++(int),=20
> =3D=3D(), !=3D(), *()=20
> and ->().
> I plan to add rbegin() and rend() and ad-hoc iterators.
>=20
> Node::get_children() returns a reference to a ChildrenList=20
> which is an=20
> attribute of Node initialised in constructor.

Sounds good. I will look at it some time to compare it to the gtkmm =
STL-like
stuff, which tries to implement as much of the STL-style interface as
possible in terms of just a few other methods, or overloads of the =
methods.

Maybe we also need
const Node::ChildrenList Node::get_children() const;

I don't think we need
const Node::ConstChildrenList Node::get_children() const;
instead, but I could be wrong.
=20
> One problem I faced is the type return by iterator::operator*().
> I first wanted to return a Node &. It is, I think, more=20
> logical, and avoid=20
> writing things like (*iter)->do_something().
> However this change the use of dynamic_cast to 'test' the=20
> type of node. If the=20
> cast fail we have an exception instead of just returning a=20
> null pointer.

That might not be too bad. People would tell us if they didn't like it. =
We
would probably want to catch them internally though.
=20
> Moreover this will make a bit heavy the switching from a=20
> version to another=20
> (but this may be acceptable from a 1.0 to 2.0 version upgrade).

Yes, that kind of change is acceptable between major versions.

> So the question is :
> What do you expect as a return type for=20
> Node::ChildrenList::iterator::operator*() ?
>=20
> remark:
> One alternative I thought of is to have :
>   Node * operator*()
> and
>   Node * operator->()
> So we can both avoid complicating use of dynamic_cast and=20
> writing stuffs like=20
> (*iter)->do_something().
> But I don't think this is a very standard behavior and would=20
> prefer not to do=20
> that.

It sounds odd.

Re: [libxml++] node iterators

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

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

Le Vendredi 23 Mai 2003 18:57, and...@am... a =E9crit :
>
> In other words, I am agreeing with Murray that it is a separate
> class.


Me too (that's what I'm saying in the part of the message you didn't quote =
:-)

So I started implementing something this way. I have the following classes :
ChildrenList, ChildrenList::iterator and ChildrenList::const_iterator

The API is STL-like :

iterator       ChildrenList::begin();
const_iterator ChildrenList::begin() const;
iterator       ChildrenList::end();
const_iterator ChildrenList::end() const;

on the different iterators we have operators ++(), ++(int), =3D=3D(), !=3D(=
), *()=20
and ->().
I plan to add rbegin() and rend() and ad-hoc iterators.

Node::get_children() returns a reference to a ChildrenList which is an=20
attribute of Node initialised in constructor.


One problem I faced is the type return by iterator::operator*().
I first wanted to return a Node &. It is, I think, more logical, and avoid=
=20
writing things like (*iter)->do_something().
However this change the use of dynamic_cast to 'test' the type of node. If =
the=20
cast fail we have an exception instead of just returning a null pointer.

Moreover this will make a bit heavy the switching from a version to another=
=20
(but this may be acceptable from a 1.0 to 2.0 version upgrade).

So the question is :
What do you expect as a return type for=20
Node::ChildrenList::iterator::operator*() ?

remark:
One alternative I thought of is to have :
  Node * operator*()
and
  Node * operator->()
So we can both avoid complicating use of dynamic_cast and writing stuffs li=
ke=20
(*iter)->do_something().
But I don't think this is a very standard behavior and would prefer not to =
do=20
that.




Regards,

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

iD8DBQE+0gs0B+sU3TyOQjARAlh8AJ0fw41qtK1QtMxB1sY0mmjmVvxAegCg4SgB
PYyxAMYlOId6SQiJz/aSl5Q=3D
=3DuUIR
=2D----END PGP SIGNATURE-----

[libxml++] [ libxmlplusplus-Patches-743222 ] Ensure assert() macro declared.

[SourceForge.net <no...@so...>]

Patches item #743222, was opened at 2003-05-25 15:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=743222&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Wakely (redi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ensure assert() macro declared.

Initial Comment:
The assert() macro is used in saxparser.cc but is not
declared. The latest g++ has cleaned up it's headers so
assert() is not declared unless you explicitly include
<assert.h> or <cassert>, so cannot be used to compile
libxml++ from CVS.
This path makes saxparser.cc include <cassert>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=743222&group_id=12999

RE: [libxml++] node iterators

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

> For begin(), just a mistake of me. What I wanted to write is :
> 
>    for( xmlpp::NodeIterator i = node.children_begin(),

How different is this from

    for( xmlpp::NodeIterator i = node.children().begin(),

Or

    for( xmlpp::NodeSet::iterator i = node.get_children().begin(),

?

What you are trying to avoid is iterating, constructing the NodeSet,
and then reiterating.

I suggest the way to do that is to make node.get_children()
(or node.children(), or...) return, not an STL set(node),.


In other words, I am agreeing with Murray that it is a separate
class.  Or, rather, a separate API, that might just delegate
to the node class.

Re: [libxml++] node iterators

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

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

Le Vendredi 23 Mai 2003 17:00, Jonathan Wakely a =E9crit :
>
> Putting my pedant's hat on for a minute I'd mention that the comments
> say you must overload the callback, but this should be "override".
> Overloading refers to reusing the name for a function with a different
> signature, but to override a virtual you must be definition have exactly
> the same signature (covariant returns excepted).

Shame on me !  :-/

> I've submitted a patch so I can sleep soundly at night.  ;-)

It's in. Thx. Have a nice sleep :-)

> I'll update my source at home and submit a new patch if it's complete
> enough, then it can be included or not as you see fit.

Ok. (Remind the ChangeLog before submiting it).

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

iD8DBQE+zj3kB+sU3TyOQjARAktjAKCYE1CrGwXjJvfhSHa3N+jueF9wcwCgy6MP
ITPY51F9rH9PffX814nFa7I=3D
=3D0cFb
=2D----END PGP SIGNATURE-----

Re: [libxml++] node iterators

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

On Fri, May 23, 2003 at 04:20:48PM +0200, Christophe de VIENNE wrote:

> > I would still recommend removing the on_get_entity() callback until
> > someone figures out how to do it properly.
> 
> what about current CVS version ?

I'm just looking at it. Disabling getEntity by default works nicely, if
anyone figures out how to do it correctly (or just has a kluge that
works well enough, as I did) they can override and enable the callback.

Putting my pedant's hat on for a minute I'd mention that the comments
say you must overload the callback, but this should be "override".
Overloading refers to reusing the name for a function with a different
signature, but to override a virtual you must be definition have exactly
the same signature (covariant returns excepted).
I've submitted a patch so I can sleep soundly at night.  ;-)

> > I did do most of the work to make the ctor take a bitset specifying the
> > callbacks to use, I could dig it out this weekend if you haven't done it
> > already.
> >
> 
> I did it only for get_entity.
> About the other callbacks, Murray seems not much enthousiastic. Personnaly I'm 
> not against so if a patch is almost ready I think it could be included.

I'll update my source at home and submit a new patch if it's complete
enough, then it can be included or not as you see fit.

jon


-- 
"I hate to advocate drugs, alcohol, violence, or insanity to anyone,
 but they've always worked for me."
	- Hunter S. Thompson

[libxml++] [ libxmlplusplus-Patches-742379 ] Correct comments in saxparser files

[SourceForge.net <no...@so...>]

Patches item #742379, was opened at 2003-05-23 14:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=742379&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Wakely (redi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Correct comments in saxparser files

Initial Comment:
The comments describing the getEntity callbacks say you
must overload the callback, but the correct term for
replacing a virtual function in a subclass is to
override. Patch replaces overload with override. It
also corrects the file name in the comment at the very
start of saxparser.h

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=742379&group_id=12999

Re: [libxml++] node iterators

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

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

Le Vendredi 23 Mai 2003 15:54, Jonathan Wakely a =E9crit :
> I came to the conclusion that entities and SAX are a complete nightmare
> and ran away with my tail between my legs.

:-)

>
> I would still recommend removing the on_get_entity() callback until
> someone figures out how to do it properly.

what about current CVS version ?

> I did do most of the work to make the ctor take a bitset specifying the
> callbacks to use, I could dig it out this weekend if you haven't done it
> already.
>

I did it only for get_entity.
About the other callbacks, Murray seems not much enthousiastic. Personnaly =
I'm=20
not against so if a patch is almost ready I think it could be included.


Cheers,

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

iD8DBQE+zi5AB+sU3TyOQjARAs1TAKCnSmZ2eQHrRBkr9KGjuO2cZfjSBgCg1BZc
XoMRPTk7r9N/yGOzoZ8iI5o=3D
=3DH3pe
=2D----END PGP SIGNATURE-----

Re: [libxml++] SaxParser and getEntity

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

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

Le Vendredi 23 Mai 2003 15:58, Jonathan Wakely a =E9crit :
> On Fri, May 23, 2003 at 12:19:32PM +0200, Christophe de VIENNE wrote:
> > While removing libxml includes from headers I faced two little problems
> > with getEntity.
> > First it has, for now, to return a libxml structure.
> > Second the default behavior to give to this callback function is not
> > trivial ( see http://mail.gnome.org/archives/xml/2003-April/msg00112.ht=
ml
> > ).
>
> If, as I believe, I was the only person using on_get_entity(),

you never know ! :-)

> then I suggest removing it entirely, at least until a better solution
> (possibly with an Entity class) is devised.

We'll see but I think the current solution is quite satisfying (you can tes=
t=20
it it's in the CVS).


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

iD8DBQE+zi0YB+sU3TyOQjARAvKAAKDiDljf0gvsRLXzahlM8M4hQW48oACdHN+A
3A9hGUQcq8cnF9wsL08VZlI=3D
=3Dndts
=2D----END PGP SIGNATURE-----

Re: [libxml++] SaxParser and getEntity

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

On Fri, May 23, 2003 at 12:19:32PM +0200, Christophe de VIENNE wrote:

> While removing libxml includes from headers I faced two little problems with 
> getEntity.
> First it has, for now, to return a libxml structure.
> Second the default behavior to give to this callback function is not trivial ( 
> see http://mail.gnome.org/archives/xml/2003-April/msg00112.html ).

If, as I believe, I was the only person using on_get_entity(), then I
suggest removing it entirely, at least until a better solution (possibly
with an Entity class) is devised.

jon


-- 
"A foolish consistency is the hobgoblin of little minds..."
	- Ralph Waldo Emerson

Re: [libxml++] node iterators

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

On Fri, May 23, 2003 at 10:42:37AM +0200, Christophe de VIENNE wrote:

> > http://sourceforge.net/tracker/index.php?func=detail&aid=708826&group_id=12
> >9 99&atid=312999
> 
> About this one I don't know what to do.
> Could somebody using on_get_entity() callback in SaxParser tell me what he 
> thinks about it ?

I've not been able to finish this work. I don't need it for work I'm
doing in my day job, so haven't had time to work on it.

I came to the conclusion that entities and SAX are a complete nightmare
and ran away with my tail between my legs.

I would still recommend removing the on_get_entity() callback until
someone figures out how to do it properly.

> What do you think about this one ? If you're OK I'll implement this 
> additionnal protected constructor I'm speaking about.
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=690193&group_id=12999&atid=312999

I did do most of the work to make the ctor take a bitset specifying the
callbacks to use, I could dig it out this weekend if you haven't done it
already.

jon


-- 
"What contemptible scoundrel stole the cork from my lunch?"
	- W.C. Fields

Re: [libxml++] Namespace support in Node::find

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

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

Le Vendredi 23 Mai 2003 07:54, oy...@ho... a =E9crit :
> I could not get Node::find to properly find things I were looking for in a
> document with two namespaces in use.  The following patch "fixed it".  Am
> I missing something, or is this missing in libxml++? (please reply
> directly, i am not on the list)

You did not miss anything, it was indeed missing in libxml++. Thanks for=20
finding this problem.

> +  if (nsl) {
> +    while (nsl[numns]) {
> +      numns++; // count number of nses
> +    };
> +  };

I'm not sure about this loop.
shouldn't it be :

xmlNsPtr *tmp =3D nsl;
while(tmp) {
	tmp =3D tmp->next;
	++numns;
};=20

> +  if (nsl) free(nsl);

I think xmlFreeNsList() is a better choice.


Can you submit a patch (with file ChangeLog updated) into the patch manager=
 ?
http://sourceforge.net/tracker/?group_id=3D12999&atid=3D312999

Thanks very much !


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

iD8DBQE+ziX1B+sU3TyOQjARAreHAJ4izxah+P8WWJS9sHGDE2MOFF/t+QCfTAbw
y/RaAwiNNo2MI3f/bKudLl4=3D
=3DKd03
=2D----END PGP SIGNATURE-----

Re: [libxml++] Namespace support in Node::find

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

Hi Oystein,

oy...@ho... wrote:
> I could not get Node::find to properly find things I were looking for in a
> document with two namespaces in use.  The following patch "fixed it".  Am
> I missing something, or is this missing in libxml++?

Excellent ! Up to date I'v used the 'namespace-uri()' function in my
xpath expressions, but that is quite verbose and doesn't really work
nicely if the xpath is itself embedded (as an attribute) into the
document, such as in the XForms standard.

Thanks a lot for the fix !

Regards,
		Stefan

[libxml++] SaxParser and getEntity

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

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

Hi,

While removing libxml includes from headers I faced two little problems wit=
h=20
getEntity.
=46irst it has, for now, to return a libxml structure.
Second the default behavior to give to this callback function is not trivia=
l (=20
see http://mail.gnome.org/archives/xml/2003-April/msg00112.html ).

I think the ideal would be to wrap xmlEntity in a xmlpp::Entity class. But =
I=20
don't want to go for such a developpement now. If somebody really need it y=
ou=20
can propose a patch.

To make minimal changes, I want to do the following :
 - add a boolean parameter to the SaxParser constructor which tells if the=
=20
on_get_entity has to be called, with default value to false.
 - In order to overload this callback function, the lib user will have to=20
include himself libxml2 header to have the definition of xmlEntity since=20
saxparser.h only make a forward declaration of the struct.

Do you agree with that ?

Once it's done the libxml headers will not be included anymore by libxml++=
=20
users.

Regards,

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

iD8DBQE+zfW1B+sU3TyOQjARAsVKAJ97NwI98YttAeUQGvHqMVLled4qoACeOl8s
cTMQpRRg/ynmFoYTAK7KPJI=3D
=3DvImA
=2D----END PGP SIGNATURE-----

[libxml++] Namespace support in Node::find

[<oy...@ho...>]

I could not get Node::find to properly find things I were looking for in a
document with two namespaces in use.  The following patch "fixed it".  Am
I missing something, or is this missing in libxml++? (please reply
directly, i am not on the list)

--- libxml++/nodes/node.cc.orig	2003-05-23 07:10:14.806340666 +0200
+++ libxml++/nodes/node.cc	2003-05-23 07:18:04.733961547 +0200
@@ -97,6 +97,19 @@
 NodeSet Node::find(const std::string& xpath) const
 {
   xmlXPathContext* ctxt = xmlXPathNewContext(_impl->doc);
+
+  // make xpath context aware of namespaces (oy...@po... 2003-05-23)
+  int numns = 0;
+  xmlNsPtr *nsl = xmlGetNsList(_impl->doc, _impl);
+  if (nsl) {
+    while (nsl[numns]) {
+      numns++; // count number of nses
+    };
+  };
+
+  ctxt->namespaces = nsl;
+  ctxt->nsNr = numns;
+
   ctxt->node = _impl;
   xmlXPathObject* result = xmlXPathEval((xmlChar*)xpath.c_str(), ctxt);
 
@@ -118,6 +131,7 @@
   }
   xmlXPathFreeObject(result);
   xmlXPathFreeContext(ctxt);
+  if (nsl) free(nsl);
 
   return nodes;
 }



-- 
Oystein Homelien, CVO             |  oy...@po...
PowerTech Information Systems AS  |  http://www.powertech.no/
Nedre Slottsgate 5, N-0157 OSLO   |  tel: +47-23-010-010, fax: +47-2220-0333

[libxml++] node iterators

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

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

Hi,

I'd like to discuss the subject of iterators inside libxml++.

We did already several month ago but this did not went to any=20
conclusion/decision.

To illustrate how I would see things, I made a small patch which implements=
 a=20
class NodeIterator, which permit to iterate through the children of a node.
I think it implements correctly the following concept from STL:
=2D - Bidirectionnal Iterator.
=2D - Input Iterator.

It's quite trivial to use. Exemple to iterate a complete tree:

void do_something(xmlpp::Node & node) {

	for( xmlpp::NodeIterator i =3D node.children_node(),
		i_end =3D xmlpp::NodeIterator();
		i !=3D i_end;
		++i)
	{
		std::cout << i->get_name() << std::endl;
		do_something(*i);
	}

};

One interesting thing is that is nodes are added/removed at the same tree=20
level, the iterator will stay valid (unless we suppress the pointed node of=
=20
course).

A const iterator is needed, but I did not do it yet.

I'd like to have comments/suggestions at least on:
 - Does this iterator have the behavior any C++ developer would expect ?
 - The class name. Should it be Node::iterator ? I'm not sure about that si=
nce=20
it would suggest Node is a container, which is not right I think.
 - Does Node::children_begin() sounds right ? It seems to me that yes.

 - Should we drop Node::get_children ? simply keep it ?
 - Should we wait for the next major version to add this feature ?



The patch (which concerns only the 'nodes' directory) also includes a littl=
e=20
change : it uses pimpl idiom so that no libxml header is included by the=20
libxml++ user.=20
I think it would be a good thing to do this for the whole library, and it's=
=20
not much work. What do you think about it ?

Comments welcome


Cheers

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

iD8DBQE+zNsQB+sU3TyOQjARAmhAAJ0f0HMTVUiJv9SrCoikIeprPYaJ+QCgxVgI
1dUmvUzJqx3rW09uoFJYfgE=3D
=3DGMZg
=2D----END PGP SIGNATURE-----

[libxml++] xmlKeepBlanksDefault

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

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

Hi,

Here is a patch to fix the xmlKeepBlanksDefault problem.
I'd like comments before commiting it.

The dom_read_write example is behaving correctly with this patch.

Cheers,

Christophe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ye10B+sU3TyOQjARAql7AJ4woMNi477sJzjlQUwpd6svH/jARgCgkOz2
V+sfWDjq9xs7Pl560VMDqEA=
=jeEz
-----END PGP SIGNATURE-----

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

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

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

Le Vendredi 16 Mai 2003 10:06, Christophe de VIENNE a =E9crit :
> I want to do a few tests and reproduce the case with pure libxml2.

Playing a bit with xmlKeepBlanksDefault(), xmlSaveFile and xmlSaveFormatFil=
e=20
it appeared that my previous observations were partly wrong.

xmlKeepBlanksDefault(0) is _not_ the default, and not what we want as a=20
default : it drops and add whitespaces. But I think this option should be=20
accessible to the user in a way or another.
So I'm thinking again of adding a per-parser and per-document option, as we=
ll=20
as a global one, to keep or not blanks.
On the other hand I don't know how this will behave in a multi-threaded=20
environnement. So only let the global parameter would be safer. I'll try=20
making tests about this.

Anyway we need to remove the calls to xmlKeepBlanksDefault() we actually do.


Cheers

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

iD8DBQE+xKmXB+sU3TyOQjARArMPAKDNfS1jBvkZQkogRIx/f+k5dTHyEgCfXI3o
necwR7YrLb1Qe3Zwxb9e7qU=3D
=3DA+2j
=2D----END PGP SIGNATURE-----

[libxml++] Re: LibXML

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

Diego,

Thanks very much for your interest and contribution to libxml++.

Having the possibility to compile libxml++ as a dll is a good thing :
I'd prefer you to propose a patch which could permit anybody to construct t=
he=20
dll, rather that propose an already compiled dll which will hardly be=20
up-to-date all the time.

If possible too, the patch would complete the already existing win32=20
workspace/project files.
Remind that filenames and directories names must not be changed.

Use the patch manager to submit the patch :
http://sourceforge.net/tracker/?atid=3D312999&group_id=3D12999&func=3Dbrowse

so any developper of the project will be able to check and comment it befor=
e=20
inclusion, and don't forget updating ChangeLog file.
If you need information about how to create a patch, see section "How do I=
=20
create a patch?" here :
http://www.gtkmm.org/bugs.shtml


One last thing : for further discussions, please use the mailing list.

Best regards,

Christophe

Le Lundi 12 Mai 2003 22:02, vous avez =E9crit :
> Gentlemen,
>
> I am writing to you because maybe I can help you with
> the project and other people with the usage of libxml.
> I created a little project which is a dynamic DLL for
> Win32 and tried to maintain as much as I could the
> spirit of the original work. I added some "#define"s
> for the dll-interface and I also changed some paths.
> The project need to be linked to iconv and libxml2
> --they are not included because of their size.
>
> Although it is a dynamic DLL, I can create a static
> version for Win32 for you if you are interested.
>
> Of course you can freely modify and distribute the
> project and if there is something I could do for you,
> you can contact me.
>
> I took the freedom of attaching the .zip file. I
> apologise if it causes problems with the storage of
> your email account.
>
> Sincerely,
> Diego Park
>
> Attach. libxmlpp.zip
>
>
> ------------
> Internet GRATIS es Yahoo! Conexi=F3n
> 4004-1010 desde Buenos Aires. Usuario: yahoo; contrase=F1a: yahoo
> M=E1s ciudades: http://ar.online.yahoo.com

RE: [libxml++] Preserving whitespace

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

> > PS I've also tried applying xml:space="preserve",
> > without luck.
> 
> What is that?

See  http://www.w3.org/TR/REC-xml#sec-white-space
in XML 1.0 spec, Second Edition.

Basically, the attribute xml:space can be attached to any element.
Value xml:space='preserve' means that whitespace must be preserved
for that element, by whatever application you are using.
Value xml:space='default' means that the application should
do whatever whitespace handling it wants to do.

Thus, an indenter might legitimately look at
<foo><bar xml:space='preserve'> 
  a
    b
c</bar><baz><biff/>blick</baz></foo>

and produce
<foo>
    <bar xml:space='preserve'> 
  a
    b
c</bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>

The attribute xml:space is pretty verbose;
typically, you might want to apply it via a style
sheet in some preliminary transformation.
Hmmm... not sure if DTDs can specify it as a 
default attribute.  Doesn't matter to me,
since my problem domain is DTD averse.



Note:  I find: the semi-indented

<foo>
    <bar xml:space='preserve'> 
  a
    b
c</bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>

pretty unreadable (and I'm used to it
from LISPing for many years).   I prefer something like:

<foo>
    <bar>
        <br/> 
        <raw>  a</raw><br/>
        <raw>    b</raw><br/>
        <raw>c</raw>
    </bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>

or 

<foo>
    <bar>
        <br/> 
        <bol/>  a<br/>
        <bol/>    b<br/>
        <bol/>c
    </bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>


(the latter form has fewer problems with 
strict nesting.)

Unfortunately, there is no standard,
although adding xml:space='preserve' 
to <raw>...</raw> comes close.




==========


> > E.g.  I might want to be processing multiple documents
> > at the same time, one of which preserves whitespace and one
> > which does not.
> 
> I don't believe libxml++ should ever destroy your significant 
> white space, and I don't think it should have even an optional 
> feature to do that.

Good. I will reupdate and see if it all works.


> In general there should be no global behaviour with libxml++.

That's what I want to hear.

There will probably be bugs, because libxml has global behaviour.
But  think the libxml people will be interested in evolving
towards non-global, context object, behaviour, too, albeit
in C syntax.

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

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

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

Or, why not use an external xml pretty printer,
such as xml_pp?

http://standards.ieee.org/resources/spasystem/twig/xml_pp.html

[libxml++] Preserving whitespace

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

> So the only thing we need is to call xmlKeepBlanksDefault(0), 
> which is done in  the parse_xx methods.
> The consequence is that, theoraticaly, the output will be 
> formatted only if something has been parsed before (I did not test this behavior).
> 
> I think that the most simple thing to do is to call 
> xmlKeepBlanksDefault(0) in write_to functions.
> On the other hand we'll have it called more than necessary. 
> So we could call it in Document::Init::Init() and remove it everywere else.

Along these lines, I've been meaning to ask:

I'd like to be able to output the text between <tag> ... </tag>
with exactly the same whitespace and formatting as when input.

This is supposedly the XML standard, according to my understanding
of when whitespace is and is not significant based on reading the
various XML standards docs.

libxml2 sems to support it, via xmlKeepBlanksDefault(1) as you mention
above.

However, I have not been able to get libxml++ to do it.
I have not investigated bypassing libxml++ and using libxml2
directly.

Reading the libxml++ code reveals several calls to xmlKeepBlanksDefault(0).
I have tried flipping them, to no effect.

---

So, the dumb question: using libxml++, how do I read
<foo>
    bar         bb
    big
    </foo>

and arrange it so that the text is exactly that,
"
    bar         bb
    big
    "
and not
"bar bb big"

?

Now, I may have embarassed myself, and it may be that the
XML rule is the latter rather than the former, but that's
not my understanding of the present standard.  The XML standards
committee mailing list has lots of discussion about when this changed.

PS I've also tried applying xml:space="preserve",
without luck.

====


By the way, something on my to do list:
Given
<foo>
<raw>
    bar         bb
    big
    </raw>
<foo>
I would like to be able to output indented text that preserves all
of the line break and whitespace info, e.g.

<foo>
  <raw>
    <line></line>
    <line>    bar         bb</line>
    <line>big</line>
    <line>    </line>
  </raw>
</foo>

i.e. using <line>..</line> to indicate line boundaries, 
with all whitespace preserved within <line>...</line>


I'd only do this for certain specified tags;
and I may or may not put xml:space="preserve".

====


Like I said, I haven't investigated this much.
But if
(a) libxml++ is supposed to preserve whitespace according
    to XML rules, and it's just me that is broken,
    please tell me
(b) if there is some magic incantation needed to get libxml++
    to preserve whitespace according to XML rules, please tell me
(b') code example appreciated.



====


Related:  libxml2 uses a number of global settings, such
as xmlKeepBlanksDefault(0).

It's not clear to me whether this are "captured", or are truly
live values.

E.g.  I might want to be processing multiple documents
at the same time, one of which preserves whitespace and one
which does not.  Is this safe with libxml2/libxml++?

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

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

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

I think I need more precise control of indentation
and whitespace significance than this,
and I'm quite happy to roll my own,
but I would appreciate some examples/documentation
as to exactly how to control it.

My biggest concern: I want all whitespace and newlines 
to be preserved on input, as is the XML standard.
This probably should be working,
but I haven't been able to get it.

Exactly what is the usage model?

(I'll be perfectly honest: I can't even tell from the name whether
xmlKeepBlanksDefault(0) or 1 preserves whitespace or not.  And
brief experiments show no effect. Being anglo-Quebecois, I am 
familiar with such Franglais name mapping problems. :-)

E.g. is the value of xmlKeepBlanksDefault sampled and preserved
at the time that an xmlpp::Document is created?

     xmlKeepBlanksDefault(0);
     xmlpp::DomParser parser0;
  

     xmlKeepBlanksDefault(1);
     xmlpp::DomParser parser1;

     parser0.parse_file("foo");  // parsed keeping blanks
     parser1.parse_file("foo");  // parsed not keeping blanks

Or is it sampled only within the parse routine?

     xmlKeepBlanksDefault(0);
     xmlpp::DomParser parser00;
     xmlpp::DomParser parser01;  

     xmlKeepBlanksDefault(1);
     xmlpp::DomParser parser10;
     xmlpp::DomParser parser11;

     xmlKeepBlanksDefault(0);  
     parser00.parse_file("foo");  // parsed keeping blanks
     xmlKeepBlanksDefault(0);  
     parser01.parse_file("foo");  // parsed not keeping blanks

     xmlKeepBlanksDefault(0);  
     parser10.parse_file("foo");  // parsed keeping blanks
     xmlKeepBlanksDefault(0);  
     parser11.parse_file("foo");  // parsed not keeping blanks

... and similarly, possibly, for the print routines.

I.e. is xmlKeepBlanks sampled at object creation time,
or at method invocation time.

Related: is whitespace preservation object oriented, or not?

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

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

> I made a few tests:
> 
> Document::write_to_string() does not format the output
> 
> Document::write_to_file() does format the ouput BUT if we use some 
> Parser::parse_xx function before, it will not (and the ouput 
> is different to 
> the one of write_to_string()).
> 
> So we have an inconsistent behavior anyway.


I think this is the inconsistency that I have been tripping over.