libxmlplusplus-general — Open discusions about libXML++

Re: [libxml++] Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance

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

Jonathan Wakely wrote:

>>Element *element = ...;
>>my_function(element->children_begin(), element->children_end());
>>
>>which is rather elegant and intuitive (and consistent with STL),
>>don't you think ?
> 
> 
> No. It is not consistent with the STL. The STL clearly defines names for
> required methods, so it should be begin() not children_begin().
> If the interface conforms to one of the STL concepts then the names
> should match to indicate as much. A STL-savvy user who reads something
> saying "The libxml++ Document is a model of an STL Forward Container"
> will asusme they can write code using the "begin()" method.

it's not the container itself that is 'standard compliant'.
But the iterators it returns are.

Stefan

[libxml++] Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance

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

On Thu, Feb 06, 2003 at 12:31:01PM -0500, Stefan Seefeld wrote:

> >I see that you have tried to avoid this by using method names such as
> >children_begin() instead of begin() but then I think it's less
> >STL-container-like.
> 
> well, it's enough to be used as an STL container:
> 
> template <typename iterator>
> void my_function(iterator begin, iterator end)
> {
>   // do something with the content here...
> }
> 
> Element *element = ...;
> my_function(element->children_begin(), element->children_end());
> 
> which is rather elegant and intuitive (and consistent with STL),
> don't you think ?

No. It is not consistent with the STL. The STL clearly defines names for
required methods, so it should be begin() not children_begin().
If the interface conforms to one of the STL concepts then the names
should match to indicate as much. A STL-savvy user who reads something
saying "The libxml++ Document is a model of an STL Forward Container"
will asusme they can write code using the "begin()" method.

jon

-- 
"Subvert the dominant paradigm!"
	- The I.O.D.

Re: [libxml++] Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance

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

Christophe de VIENNE wrote:

> I did not look at xpath in libxml2 but I guess that NodeSet could be a wrapper 
> around the libxml2 structure returned by xpath operations, and implement 
> STL-like methods which access the libxml2 container.

eventually, may be (I don't fully understan that structure either, as it
may contain more than just a 'NodeSet'). For now I think it's *much* 
simpler to copy the references into a std::vector instead of rewriting
a new container that wrapps this libxml2 structure.

On the other hand, DV hinted at a potential problem with nodes that 
exist only temporarily (namespace attributes, I think), which are 
deleted by libxml2 as soon as the xpath lookup is over. We'll run into
a bug as soon as we use xpath to find these namespace attributes, as the
returned nodes (in our NodeSet container) wouldn't be valid as soon as
the xpath lookup is over (i.e. xmlXPathFreeObject is called).

That's one thing where I'm reluctant to go for a complete API *right 
now*, just because it's complex, and chances that anybody will run into
it are tiny. But yes, eventually these issues have to be addressed.

Stefan

[libxml++] Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance

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

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

Le Jeudi 6 F=E9vrier 2003 18:31, Stefan Seefeld a =E9crit :
> I just think it is intuitive to use iterators to walk over child nodes
> (or attributes). In particular, instead of doubling the semantics of
> libxml2 (which uses doubly linked lists to hold child nodes), we could
> access that container directly instead of using our own ('NodeList').

that make sens.

>
> Of course, if the container itself is temporary, such as in case of
> the 'NodeSet' (a name defined in the XML spec) which is returned by
> an xpath 'find' operation, there is no way around.

I did not look at xpath in libxml2 but I guess that NodeSet could be a wrap=
per=20
around the libxml2 structure returned by xpath operations, and implement=20
STL-like methods which access the libxml2 container.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Qp/xB+sU3TyOQjARAr1ZAKDlh+2YHxL4ajSf0XT52TgLYcfN4wCgmcch
BY4DjJ7iDLBkZ1zOJ0E9XeA=3D
=3D7Und
=2D----END PGP SIGNATURE-----

[libxml++] Re: [Libxmlplusplus-general] autogen.sh without configure?

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

Christophe de VIENNE wrote:

> But after step 2 the Makefile are not generated, and the rule 'dist', which I 
> personnaly use to make the source release, will not work...

I don't understand. Yes, to be able to 'make' anything, you first need
to configure. That's how it works now, and it will continue to be that
way. What's holding you back from calling 'make dist' in the build tree
(which *could* be identical to the source tree).

> Unless one really doesn't want to use 'make dist', I don't really get the goal 
> of separating step 2 and 3. The rare times I needed to do that I did it by 
> hand for once.

again, a distribution will contain the 'configure' script, as well as
all the *.in templates. This means the user doesn't need any autotools.
Further, users can build libxml++ without write access to the source
tree. (that is important when you are working on large projects with
automated build processes, where you want to control who can modify
what).

Stefan

[libxml++] Re: [Libxmlplusplus-general] dom_parser example using Visitor pattern

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

Christophe de VIENNE wrote:

>>plus a 'Visitor' base class that has one 'visit' method per node type.
>>(to be implemented by users)
> 
> 
> Implemented by users, but with a default empty implementation I think.

yep.

> We could then make a visitor which will 'see' only the TextNodes of a Document 
> for example.

right.

Stefan

Re: [Libxmlplusplus-general] autogen.sh without configure?

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

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

Le Jeudi 6 F=E9vrier 2003 18:06, Stefan Seefeld a =E9crit :
> It is important to note that a source release (or snapshot) is done
> after step 2, so users don't need the autotools.

But after step 2 the Makefile are not generated, and the rule 'dist', which=
 I=20
personnaly use to make the source release, will not work...

Unless one really doesn't want to use 'make dist', I don't really get the g=
oal=20
of separating step 2 and 3. The rare times I needed to do that I did it by=
=20
hand for once.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+QpxKB+sU3TyOQjARAm+6AJ0dYJLkVAy+NyFXhTxTC3C+5dvMIgCgpBoX
YnvkPy7RujvS3DLEypnIED4=3D
=3DAZaF
=2D----END PGP SIGNATURE-----

Re: [Libxmlplusplus-general] dom_parser example using Visitor pattern

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

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

Le Jeudi 6 F=E9vrier 2003 17:50, Stefan Seefeld a =E9crit :
> I agree that this is quite independent of the rest. It merely addresses
> the type safety issue, i.e. it helps us recover the exact type of a
> child node.
>
> In terms of API complexity it requires all nodes to have an 'accept'
> method, to be implemented as
>
> void Element::accept(Visitor *v) { v->visit_element(this);}
>
> plus a 'Visitor' base class that has one 'visit' method per node type.
> (to be implemented by users)

Implemented by users, but with a default empty implementation I think.
We could then make a visitor which will 'see' only the TextNodes of a Docum=
ent=20
for example.

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

iD8DBQE+QptYB+sU3TyOQjARAt7NAJwNjzfZ9zdRvNgIpZer7rDd6cbIuACeOwOk
ecXYt+qPWy/SeRV3K3PZ4/4=3D
=3DPn76
=2D----END PGP SIGNATURE-----

Re: [Libxmlplusplus-general] resume of one day's work

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

Murray Cumming wrote:
> On Tue, 2003-02-04 at 15:49, Stefan Seefeld wrote:
> 
>>Murray Cumming wrote:
>>
>>>I haven't looked at this yet, but didn't I say that you shouldn't take
>>>cvs access as permission to just check in whatever you like? The need to
>>>revise your patch 6 times should have shown you that you probably need
>>>to go a bit slower. Your arrogance is beginning to astound me.
>>
>>my WHAT ? Now you calm down a bit, will you ?
>>
>>I'v sent various mails to the list discussing my different proposed 
>>additions, and got some positive feedback. Are you able to browse the
>>archives ?
> 
> 
> Everything seems to be sorted out now. I'll just respond quickly again
> to this. The issue is not whether the changes are appropriate - The
> point is that you are not a maintainer so you should not make changes
> without getting permission first - certainly not API changes.

Ok, now that is something to discuss. As I repeatedly stated here, I
fully agree that having write permission comes with a lot of
responsability, for example not to apply 'random changes' as you call
it.

I never did.

Every single change I did was proposed days ahead on the list. Nobody
objected. In the contrary, most suggestions were supported.
In particular, Christophe (the maintainer) never told me to do this or
that, and there is nothing defining what rights I have and what not.

I really don't understand where you get the idea that I have to get
explicit permission for each checkin. That's not my understanding on
what cvs write permissions are for.
Had I known, I may not have taken the trouble to join the project, as it
is just too cumbersome (instead, I would have rolled my own little 
project and sent regular mails informing you about stuff I think may
interest you so you could create patches and apply them yourself).

But again, I think the fun is really to work this out and get an
agreement on how libxml++ should look like in its final form.

> I asked
> Christophe not to give you cvs write access immediately so that you
> would have the chance to develop the correct habits first. In my
> experience that is a smoother process.

 From my perspective the problem here is that you have a very strange
definition of 'correct habits'. You are certainly not getting me to
ask you for checkin permission each time I want to make an checkin.

I *never* would make API changes without asking for agreement. So far,
the only API changes I made are additions, and I asked whether people
would agree on them. Since nobody objected (in what I considered a
reasonable time frame), I took it a checkin to that effect would be
fine.

>>Who are you that you give me permission or not to do things ?
> 
> 
> I am the person who revived the project, and created the stable/unstable
> release plans.

Where are those plans ? The only thing about a release I heared was
you discussing with Christophe about whether or not to include my
first patch into the 1.0 branch (and thus, release).

> I am the person who has successfully released and
> maintained stable APIs for gtkmm, gnomemm and libsigc++ among others,
> sucessfully encouraging and integrating many developers.

Now that is quite beside the point. Or do you want me to number all
the projects I have been creating/leading/maintaining, too ? That
doesn't get us anywhere. We are both developers in the libxml++ project,
where we have to show our merrits.

In a nutshell, I'd like to see clearly how you (and the other project
participants) envision the project's future (where do we want this 
project to go ?) and the way it is maintained.
For me it's really just a matter of efficiency. I'm looking forward
to have constructive and open-minded discussions about the project's
design and code. But I'm a bit worried about the overhead implied by
an overly restrictive development process.

Really, the thing may be as simple as stating clearly what kind of
changes are acceptable and what are not.

Stefan

Re: [Libxmlplusplus-general] resume of one day's work

[<mu...@t-...>]

On Tue, 2003-02-04 at 15:49, Stefan Seefeld wrote:
> Murray Cumming wrote:
> > I haven't looked at this yet, but didn't I say that you shouldn't take
> > cvs access as permission to just check in whatever you like? The need to
> > revise your patch 6 times should have shown you that you probably need
> > to go a bit slower. Your arrogance is beginning to astound me.
> 
> my WHAT ? Now you calm down a bit, will you ?
> 
> I'v sent various mails to the list discussing my different proposed 
> additions, and got some positive feedback. Are you able to browse the
> archives ?

Everything seems to be sorted out now. I'll just respond quickly again
to this. The issue is not whether the changes are appropriate - The
point is that you are not a maintainer so you should not make changes
without getting permission first - certainly not API changes. I asked
Christophe not to give you cvs write access immediately so that you
would have the chance to develop the correct habits first. In my
experience that is a smoother process.

> Who are you that you give me permission or not to do things ?

I am the person who revived the project, and created the stable/unstable
release plans. I am the person who has successfully released and
maintained stable APIs for gtkmm, gnomemm and libsigc++ among others,
sucessfully encouraging and integrating many developers. I know how to
do this stuff. I am not an official maintainer of libxml++ because I am
trying to avoid extra responsibilities, but Christophe has OKed all of
my plans.

Again, everything seems to be sorted out now. 

-- 
Murray Cumming
mu...@us...
www.murrayc.com

Re: [Libxmlplusplus-general] resume of one day's work

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

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

Le Mardi 4 F=E9vrier 2003 17:32, Stefan Seefeld a =E9crit :
> In that light, I would really suggest we roll back *all* changes from my
> side, i.e. branch for a 1.0-release using the version just before my
> first patch went in. I think that, while quite limitted feature-wise,
> this is a consistent and self-contained version.

That's ok for me.

We'll do branching by the weekend.

> Looking forward to a constructive and open-minded discussion,

great, me too :)

Best regards,

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

iEYEARECAAYFAj4/9xQACgkQB+sU3TyOQjDtGwCgwsbn0SF1ptVyh/xE1mDItK6f
axoAn3EwhKAi7cGQAy2hdEv4JamZu8Re
=3Db4JR
=2D----END PGP SIGNATURE-----

Re: [Libxmlplusplus-general] resume of one day's work

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

Hey Rolf,

Rolf Dubitzky wrote:

>  Murray did a lot of work to revive libxml++ development and to get it to an 
> API stable version! But, I also think it might be a good idea to go towards a 
> real libxml-wrapper, rather than a half reimplementation. But kind, gentle, 
> and after 1.0 ? 

sure. Indeed, I didn't know how many people currently used libxml++, and 
thus how big an impact my proposed changes would be. I think that the 
change with the biggest impact is the 'paradigm shift' away from a 
library implementing itself a dom, towards a thin libxml2 wrapper.

In that light, I would really suggest we roll back *all* changes from my
side, i.e. branch for a 1.0-release using the version just before my
first patch went in. I think that, while quite limitted feature-wise,
this is a consistent and self-contained version.

My patch and subsequent checkins all work towards a different goal, so 
their stabilization may make a good target for the next milestone (1.2, 
say).

Doing this would allow the 1.0 branch to stabilize, while not halting
future evolution of the developmental branch. And, Murray, be assured,
I'll wait with any future checkins for you to be back so we can make 
sure we have a common vision of where all this is heading.

Looking forward to a constructive and open-minded discussion,

Stefan

Re: Mediation attempt (was Re: [Libxmlplusplus-general] resume of one day's work)

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

Hi Christophe,

Christophe de VIENNE wrote:

> I won't give reason to one or another of the protagonists, I just don't want 
> the good work of both of you not to be loosed for libxml++. You both have 
> more experience than me and you cannot image how I appreciate your 
> participation on the project.

thanks for the encouraging words. Yes indeed, I'd *much* appreciate to
keep our *common* efford going. While working together can be hard at
times, I definitely think it is worth the efford.

> Stefan, the last modifications you added are definitly good ones, but to 
> preserve everybody's nerves, we'll keep them (iterator stuffs) on the 
> unstable branch, and the future 1.0 version will keep the current API.

ok, I'm fine with that. But please lets have a close look at the old API
and clearly identify the problems with it. There are quite a number of
places where the code will either leak or at least not be clear enough
to developers as to what happens, and what the user/developer is
expected to do (my old song of ownership semantics...)

In fact, I think we should go over the changes (I *did* try hard to keep
each individual commit in focus on a precise and atomic goal) and
evaluate whether they present a fix that's worth preserving for the 1.0
stable branch or not. For example the redefinition of AttributeMap is -
while a major API change - clearly a fix of a memory leak.

> As Murray always did on this project, I invite you to warn us if you're going 
> to commit some changes (backward compatible or not) in the API, so such 
> situations won't (I hope) happen again.

ok. Again, I did discuss all of my changes on the list. May be I should
have waited longer for feedback, but there were either no or only
positive comments to the issues I addressed, so I didn't anticipate any
opposition.

> Some discussions we had about evolution of the lib were implicitly concerning 
> the future unstable branch. I could have been more explicit about it, sorry.
> 
> Now I let you both "laver votre linge sale entre vous" ;-)

d'accord (hors de la liste de courriels si possible).

Kind regards,
		Stefan

Re: [Libxmlplusplus-general] resume of one day's work

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

> > to go a bit slower. Your arrogance is beginning to astound me.
>
> my WHAT ? Now you calm down a bit, will you ?

Hi guys, 

 could you maybe call down _both_ a little. There a actually people using 
libxml++. It doesn't really help if the API and the whole project philosophy 
gets turned upside down everytime a new developer steps up. 
 I know my opinion may be irrelevant, but as a user, I take the freedom to 
express my whish for a API stable 1.0 release before you start to tear each 
other apart over major changes of the whole library design?
 Murray did a lot of work to revive libxml++ development and to get it to an 
API stable version! But, I also think it might be a good idea to go towards a 
real libxml-wrapper, rather than a half reimplementation. But kind, gentle, 
and after 1.0 ? 

peace brothers ;-)
Rolf

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

Mediation attempt (was Re: [Libxmlplusplus-general] resume of one day's work)

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

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

Hi folks,

It seems we have a small problem :-/

As the official maintener of libxml++, I must say a few words. My goal here is 
to clarify the situation, and to avoid the project to 

A few weeks ago we decided with Murray that current API would be the 1.0 one, 
and that no changes would be done on it, except for bugfix or adding 
validation.
Then Stefan came with really good ideas to make libxml++ a better wrapper of 
libxml++. More than that, it would permit to implement easily some features 
like xpath.
I'm reminding this to you since, in my opinion, it permit to andersand why 
Murray did not appreciate that accessors has been *added*, and so the API 
changed (the initial patch of Stefan almost did not change the API, just 
reimplemented it differently).
Now I must admit that the tone he used would have irritate almost anybody.

I won't give reason to one or another of the protagonists, I just don't want 
the good work of both of you not to be loosed for libxml++. You both have 
more experience than me and you cannot image how I appreciate your 
participation on the project.

Stefan, the last modifications you added are definitly good ones, but to 
preserve everybody's nerves, we'll keep them (iterator stuffs) on the 
unstable branch, and the future 1.0 version will keep the current API.
As Murray always did on this project, I invite you to warn us if you're going 
to commit some changes (backward compatible or not) in the API, so such 
situations won't (I hope) happen again.
Some discussions we had about evolution of the lib were implicitly concerning 
the future unstable branch. I could have been more explicit about it, sorry.

Now I let you both "laver votre linge sale entre vous" ;-)

Best regards,

Christophe

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

iEYEARECAAYFAj4/4PMACgkQB+sU3TyOQjBBSACeOuR+19qW2kR3XjcoPj5br7Qy
LicAoI7Wk9tLLM/jP1PNY/7Wb22oxqXQ
=aQ4h
-----END PGP SIGNATURE-----

Re: [Libxmlplusplus-general] resume of one day's work

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

Murray Cumming wrote:
> On Tue, 2003-02-04 at 08:21, Stefan Seefeld wrote:
> 
>>hi there,
>>
>>I'v just checked in the latest bits and pieces of today's round
>>of enhancements. Here is a list:
> 
> 
> I haven't looked at this yet, but didn't I say that you shouldn't take
> cvs access as permission to just check in whatever you like? The need to
> revise your patch 6 times should have shown you that you probably need
> to go a bit slower. Your arrogance is beginning to astound me.

my WHAT ? Now you calm down a bit, will you ?

I'v sent various mails to the list discussing my different proposed 
additions, and got some positive feedback. Are you able to browse the
archives ?

I didn't do *any* backward incompatible changes, beside redefining
the AttributeMap used by the SaxParser.

Further, I fixed quite a number of issues with the old API, and
quite massively enhanced its capabilities (simply by allowing more
calls to be directly mapped to libxml2).

So, in the light of all this, who are you that you call me arrogant ?

>>* create a 'Document' type
>>* make 'Attribute' a subclass of 'Node'
>>* enhance the tree manipulation API, adding a Node::child_iterator
>>   type, as well as new 'insert_child', and 'append_child' methods
>>   (in accordance with the usual STL nomenclature)
>>* remove more memory leaks (SaxParser now has its own 'AttributeMap',
>>   independent from Node types
>>* new 'Node::find' and 'Node::get_path' methods for use with xpath lookup
> 
> 
> Who gave you permission to make these major API changes? As far as I
> know we have not branched yet. Now we will have to do a lot of work to
> branch and revert these changes in the 1.0 branch.

What's wrong with these changes going into 1.0 ? What issues do they
generate ? There isn't anything (not in cvs, nor in the mailing list)
hinting at what kind of changes are acceptable before a branch and what
not. My interpretation of the recent discussions here on the list were
that the enhancements / clarifications in the API are well worth to go
into 1.0. And really, what I did yesterday is just a continuation
/wrap-up of the patch that youself checked in.

Again, I agree that developers working on a common project ought to
stick to a common vision. I think I did my best to do that, and I'd like
to continue to do that and contribute to enhance libxml++.

It's *your* attitude that I find quite a bit upsetting. It's your
commanding tone that's turning me off quite a lot. Who are you that you
give me permission or not to do things ?
It's not as if I want to subvert the project. Again, if there were any
clear guidelines telling me that libxml++ is currently in a feature
freeze or something, I obviously would have been more careful.

Could you please at least have a look at the changes before calling
me words ? Did you actually look at the new demo ?

>>What is the reason for the libxml++ code to be split over a set of subdirs ?
>>Is that really necessary ?
> 
> 
> Yes. It's organisation.

Can you elaborate a bit ?

>> Now that 'Attribute' is a node, it is also inconsistent.
>>I would suggest to put all libxml++/nodes/ source files into a single place with the
>>rest.
>>
>>Oh, and can we take out the call to './configure' from the autogen.sh script ?
> 
> 
> No, I'd rather that we didn't.

*That* is what I call arrogant. I'm trying to enhance libxml++, and you
don't even take the time explaining why you think the current situation
is better than my proposed changes.

You do everything to drive away contributors, at least me. I'm seriously
considering to just roll my own. It isn't that hard, I just hoped we
could reduce the redundancy and work together instead. Your immature
attitude makes that very hard.

What have the others here on the list to say on these issues ?
Does anybody else worry about the project's stability due to my checkins ?


Stefan

Re: [Libxmlplusplus-general] resume of one day's work

[<mu...@t-...>]

On Tue, 2003-02-04 at 08:21, Stefan Seefeld wrote:
> hi there,
> 
> I'v just checked in the latest bits and pieces of today's round
> of enhancements. Here is a list:

I haven't looked at this yet, but didn't I say that you shouldn't take
cvs access as permission to just check in whatever you like? The need to
revise your patch 6 times should have shown you that you probably need
to go a bit slower. Your arrogance is beginning to astound me.

> * create a 'Document' type
> * make 'Attribute' a subclass of 'Node'
> * enhance the tree manipulation API, adding a Node::child_iterator
>    type, as well as new 'insert_child', and 'append_child' methods
>    (in accordance with the usual STL nomenclature)
> * remove more memory leaks (SaxParser now has its own 'AttributeMap',
>    independent from Node types
> * new 'Node::find' and 'Node::get_path' methods for use with xpath lookup

Who gave you permission to make these major API changes? As far as I
know we have not branched yet. Now we will have to do a lot of work to
branch and revert these changes in the 1.0 branch.

> All this is illustrated in a new example in examples/dom/. The example takes
> an existing docbook 'article' and modifies it, and does a simple (xpath
> based) validation test.
> 
> Here are some further enhancements I'd like to work on:
> 
> * add a 'Visitor' class to get rid of all the dynamic_casts in the existing
>    examples

Let's patches for all the other stuff please, and let's apply them until
we've branched.

> * clean up the tree access/modification API. In particular:
>    - get rid of all methods involving NodeLists. Use iterators instead.
>    - get rid of [add,get] *_content (iterators, again...)
>    - define what 'get_content' should do if this isn't a text (etc.) node.
> * decide who can create Nodes, who owns them if they are taken out of a document,
>    etc. May be a 'Store' object may help...
> 
> What is the reason for the libxml++ code to be split over a set of subdirs ?
> Is that really necessary ?

Yes. It's organisation.

>  Now that 'Attribute' is a node, it is also inconsistent.
> I would suggest to put all libxml++/nodes/ source files into a single place with the
> rest.
> 
> Oh, and can we take out the call to './configure' from the autogen.sh script ?

No, I'd rather that we didn't.

> I'd like to be able to configure (and build) in a separate build tree, which
> currently isn't possible.

Feel free to make your own autogen.sh locally.

> 
> Any comments concerning the new code (please look into the examples/dom/ demo !)
> are highly appreciated...
> 
> Regards,
> 		Stefan
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
-- 
Murray Cumming
mu...@us...
www.murrayc.com

[Libxmlplusplus-general] resume of one day's work

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

hi there,

I'v just checked in the latest bits and pieces of today's round
of enhancements. Here is a list:

* create a 'Document' type
* make 'Attribute' a subclass of 'Node'
* enhance the tree manipulation API, adding a Node::child_iterator
   type, as well as new 'insert_child', and 'append_child' methods
   (in accordance with the usual STL nomenclature)
* remove more memory leaks (SaxParser now has its own 'AttributeMap',
   independent from Node types
* new 'Node::find' and 'Node::get_path' methods for use with xpath lookup

All this is illustrated in a new example in examples/dom/. The example takes
an existing docbook 'article' and modifies it, and does a simple (xpath
based) validation test.

Here are some further enhancements I'd like to work on:

* add a 'Visitor' class to get rid of all the dynamic_casts in the existing
   examples
* clean up the tree access/modification API. In particular:
   - get rid of all methods involving NodeLists. Use iterators instead.
   - get rid of [add,get] *_content (iterators, again...)
   - define what 'get_content' should do if this isn't a text (etc.) node.
* decide who can create Nodes, who owns them if they are taken out of a document,
   etc. May be a 'Store' object may help...

What is the reason for the libxml++ code to be split over a set of subdirs ?
Is that really necessary ? Now that 'Attribute' is a node, it is also inconsistent.
I would suggest to put all libxml++/nodes/ source files into a single place with the
rest.

Oh, and can we take out the call to './configure' from the autogen.sh script ?
I'd like to be able to configure (and build) in a separate build tree, which
currently isn't possible.

Any comments concerning the new code (please look into the examples/dom/ demo !)
are highly appreciated...

Regards,
		Stefan

[Libxmlplusplus-general] libxml(2) tests in configure

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

acinclude.m4 tests for libxml2 (now version 2.5.1) and, if that fails,
for libxml. That doesn't seem correct. Shouldn't we remove the according
block of code ?

Stefan

Re: [Libxmlplusplus-general] DOM traversal and the semantics of 'get_attribute', 'get_content', etc.

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

It is reasonable to query the content of a given node. But what
should it return ? Before my patch, Node::get_child_content
returned an array of TextNodes. That seems to me wrong. It is
somewhat in the middle between two justifiable meanings:

1) return the set of child nodes
2) return the stringified content

ad 1)

as I suggested, I think we do need a (better) API to traver the tree.
I think the best way to achieve this (and the most intuitive one in C++)
is using iterators. In fact, if no-one is objecting, I'd like to add
that (may be still today)

ad 2)

stringified content means the actual CDATA, i.e. all markup stripped off
(equivalent of 'xsl:value-of', as opposed to 'xsl:copy-of').

I do think that 'get_content' should do 2).

Stefan

[Libxmlplusplus-general] DOM traversal and the semantics of 'get_attribute', 'get_content', etc.

[Stefan S. <ste...@or...>]

hi there,

while methods such as 'get_attribute' or 'get_content' look fairly
innocent and just like arbitrary accessors, they are not. They may
involve quite a bit of internal processing, such as entity replacement
or default value lookup in the dtd/schema.

It is therefor important to clearly define what those methods should
do, or, if necessary, provide alternative ways to access the 'raw'
content vs. access the preprocessed data.

For example, with the single attribute access point 'get_attribute'
we either can figure out what attribute was really given in the 'raw'
document, or, what the attribute logically is (i.e. in case there is
a default value, take this if it is not explicitely given).

Is only one of them valid in the context of xml ? If so, it's probably
the latter. If not, we may consider adding a new accessor, or add a
bool parameter to 'get_attribute'. Actually, in case of attributes,
there is another solution: just disconnect the document from its dtd,
so all the xml parser can access is the raw document data itself.

However, the problem is really a fundamental one, which is why I'd like
to discuss it in more general terms.

Regards,
		Stefan

Re: [Libxmlplusplus-general] coding style issues

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

hi Jonathan,

thanks for the clarification ! Fortunately the way
I use the 'using' directive in my patch is as in (a),
i.e. to lift an existing method from the 'protected'
into the 'public' part, so we should be fine.

Regards,
		Stefan

Re: [Libxmlplusplus-general] coding style issues

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

On Sat, Feb 01, 2003 at 05:19:00PM -0500, Stefan Seefeld wrote:

> >GCC 2.95 doesn't support using declarations at class scope if the name
> >is subsequently overloaded, so hidden functions must be redefined.
      ^^^^^^^^^^^^^^^^^^^^^^^
> >RedHat's GCC 2.96 does support such using decls, but FreeBSD's 2.95.4
> >doesn't, and AFAIK Debian's 2.95.4 doesn't either.
> >Should libxml++ work with GCC 2.95 ?
> 
> I'm puzzled, I just tried to compile this chunk with a home-built 2.95.3:
> 
> ----
> class A
> {
> protected:
>   void foobar();
> };
> 
> class B : public A
> {
> public:
>   using A::foobar;
    void foobar(int);   // overload, hides A::foobar
> };
> ----
> 
> with 'gcc version 2.95.3 20010315 (release)'
> 
> and it worked fine.

Yes, this is case (a) in the original mail, where a using decl changes
the access to a name. GCC 2.95 supports this. It doesn't support case (b),
where a using decl prevents name hiding. If you make the change above
(overload foobar in the derived class, which would hide A::foobar if the
using decl weren't present) and GCC 2.95 should fail with this error:

hiding3.cc:12: cannot adjust access to `void A::foobar()' in `class B'
hiding3.cc:11:   because of local method `void B::foobar(int)' with same name

Even the error message implies that in GCC 2.95 the only purpose of a
using decl is to change access, as in case (a), whereas the C++ standard
intends using decls to also prevent name-hiding, case (b).

If you now try to call A::foobar through an object of type B, like so:

int main()
{
  B b;
  b.foobar();
}

then you should get this error:

hiding3.cc: In function `int main()':
hiding3.cc:17: no matching function for call to `B::foobar ()'
hiding3.cc:11: candidates are: void B::foobar(int)

Therefore to prevent name-hiding you must modify B like so:

class B : public A
{
public:
  void foobar() { A::foobar(); }  // redefine, using A's implementation
  void foobar(int);
};

This only applies to case (b), where the name is overloaded in the
derived class. This fails for me with GCC 2.95.2, FreeBSD's (unofficial)
2.95.4 and Debian's (unofficial) 2.95.4, but works with RedHat's 2.96.
I can't check that it fails for the official 2.95.3, but I would be
surprised if it doesn't.

jon


-- 
"A scientific theory should be as simple as possible, but no simpler."
	- Albert Einstein

Re: [Libxmlplusplus-general] bugs?

[Philipp K. <pk...@sp...>]

>
>
>Hi,
>
>Could you provide us a patch through the patch manager ?
>
>Thanks very much
>
>Christophe
>  
>
Sorry, but learning to use that patch manager probably would take more 
effort
than it took to fix the bugs and compile libxml++ on my system, so I'll 
probably
just make the changes again each time I download a new release without 
the bugs
fixed.

P.

Re: [Libxmlplusplus-general] Parser abstraction

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

Le Dimanche 2 F=E9vrier 2003 00:12, Stefan Seefeld a =E9crit :
> Christophe de Vienne wrote:
> > The situation I was thinking of would be to create a class that is able
> > to read a document from a special source, for exemple network with a
> > weird protocol, and to which we could give the Parser which has to parse
> > it.
>
> well, for 'special sources' there is the 'std::streambuf' abstraction in
> C++. Us that when you want to abstract away the physical nature of the
> source you are reading from.
>

right

> > I'd like to have some more points of view since we'll have to make a
> > decision at last.
>
> heh, you are right. Let's listen to the others :-)

yes

Christophe