libxmlplusplus-general — Open discusions about libXML++

Re: [libxml++] Rename Element::add_content() to add_text_content?

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

On Fri, 2003-10-24 at 19:06, Christophe de Vienne wrote:

> We don't have Element::add_entity_reference() I think.
> 
> If needed please provide a patch.

Heh, wow, this makes me wonder if we have been following each others'
discussions at all! :-)  Most of my discussion in this matter have been
with murraryc and Daniel Veillard, so I do not intend to critisize you.
add_entity_reference() is what I have been wanting to have for some
time. However, it is quite difficult to implement, not directly
available through libxml2, and we would have to pull code from libxml2,
or submit patches to libxml2 to expose some facilities it uses
internally.
 

RE: [libxml++] Re: Threatening 1.0 again

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

> From: lib...@li... 
> > What is happening with the SAX API changes for namespaces?  
> I've had 
> > to add quite a bit of code to cope with them correctly.
> 
> Nothing needs to be done here because, by nature, the SAX API 
> is not aware of namespaces.

Do you mean the libxml SAX Parser, or SAX Parsers in general? I can imagine
that some SAX-like parser might have a namespace declaration callback, and
might pass the namespace prefix and/or uri for each node.

> Your derived SAX parser must 
> decide how to deal with them. It is not hard to see if an 
> attribute name equals "xmlns" to check for a namespace 
> declaration or string.find(':') to look for a namespace 
> prefix on an element or attribute.

Re: [libxml++] Rename Element::add_content() to add_text_content?

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

Dan Dennedy wrote:

>Please add:
>CommentNode* Document::add_comment(const std::string& content)
>{
>  xmlNode* node = xmlNewComment((xmlChar*)content.c_str());
>  xmlAddChild( (xmlNode*) _impl, node);
>  return static_cast<CommentNode*>(node->_private);
>}
>
>comments can be outside the root node too!
>
>  
>
Good point. I'll do that.


>>I have also thought about removing the add_ methods() becauase the set_()
>>methods do the same thing 90% of the time. The add_ methods are only useful
>>if you want to add more than one text or comment node. I suppose that's
>>slightly useful.
>>    
>>
>
>I think we should keep add_ in addition to set_ because a node can have
>a child node list containing more than one text contents node. What if I
>am able to implement my derived DOM such that in my derived SAX parser I
>can add entity references to the DOM I am building? I then need to be
>able to add_text(), add_entity_reference(), and add_text(), e.g. 
>
>  
>

We don't have Element::add_entity_reference() I think.

If needed please provide a patch.


Thanks !


Christophe

[libxml++] sax parser

[Tim <ti...@st...>]

Hi everyone

I am using the sax parser example together with this xml file (see below). The 
xml file is from a ISP and just reports your usage and any meassges, your 
plan etc,the format for this file doesn't change only the data obviouslly. My 
problem is the order in which things get printed to the screen, for eg... in 
the <MESSAGE the "TITLE" comes after "TEXT", when using that sax_example how 
can i change the order in which it is printed because i would like to be able 
to print the "title" and than "test" in that order. Also i need to be able to 
add up the "DOWNLOADS" in <DATA to give a total. Any help would be great

Thanks



*******************************XML-FILE********************************************
<USAGE START_DATE="21-10-2003" GRANULARITY="DAY" VERSION="3" 
END_DATE="20-11-2003">
<TRAFFIC DESCRIPTION="Normal Billable Traffic">
<DATA UPLOADS="0" DOWNLOADS="51" TYPE="Standard" TIMESTAMP="2003-10-21 
00:00:00"/>
<DATA UPLOADS="0" DOWNLOADS="199" TYPE="Standard" TIMESTAMP="2003-10-22 
00:00:00"/>
<DATA UPLOADS="0" DOWNLOADS="64" TYPE="Standard" TIMESTAMP="2003-10-23 
00:00:00"/>
<DATA UPLOADS="0" DOWNLOADS="2" TYPE="Standard" TIMESTAMP="2003-10-24 
00:00:00"/>
</TRAFFIC>
<TRAFFIC DESCRIPTION="Free Traffic">
<DATA UPLOADS="0" DOWNLOADS="0" TYPE="Standard" TIMESTAMP="2003-10-21 
00:00:00"/>
<DATA UPLOADS="0" DOWNLOADS="0" TYPE="Standard" TIMESTAMP="2003-10-22 
00:00:00"/>
<DATA UPLOADS="0" DOWNLOADS="1" TYPE="Standard" TIMESTAMP="2003-10-23 
00:00:00"/>
<DATA UPLOADS="0" DOWNLOADS="0" TYPE="Standard" TIMESTAMP="2003-10-24 
00:00:00"/>
</TRAFFIC>
<DATABLOCKS/>
<MESSAGE TEXT="Between 5:15pm to 6:10pm there was a disruption to the ADSL 
Service in Canberra. We apologise for any inconvenience this may have caused.   
" ID="1066621200" TITLE="Canberra ADSL disruption" TIMESTAMP="Sun Oct 19 
22:40 2003"/>
<MESSAGE TEXT="We are currently experiencing dataflow problems for ADSL 
customers in Canberra.  At this stage only SOHO and Home ADSL customers are 
affected. This is being investigated.   " ID="1067005500" TITLE="Service 
Disruption: Canberra" TIMESTAMP="Fri Oct 24 09:25 2003"/>
<MESSAGE TEXT="The disruption to service in Canberra is resolved.  Restore 
time: 9:49am EST   " ID="1067007720" TITLE="Service Disruption: Canberra 
RESOLVED" TIMESTAMP="Fri Oct 24 10:02 2003"/>
<PLAN DESCRIPTION="Home 512 Flat Rate">
<LIMIT NAME="Standard" MEGABYTES="6000"/>
</PLAN>
</USAGE>

Re: [libxml++] Threatening 1.0 again

[Matthew W. <ma...@al...>]

All sounds good to me, I could really do with a stable API/ABI to 
target. I'm only using the DOM classes, and they're absolutely fine, so 
I'm quite happy with regard to that.

Matthew
A satisfied user (especially when there's a stable version)

Christophe de VIENNE wrote:
> Ok. We wait for SaxParser & Entities to be finished (and included in a 
> release), and then branch :
> - The stable libxml++ will be on a branch tagged 'BRANCH-1_0', and the 
> unstable one in the HEAD.
> - The version of stable libxml++ will be 1.0 (surprising isn't it ?), 
> and the unstable 1.1, as you suggested a long time ago.
> - We may wait a bit after branching before releasing a 1.0 version (with 
> the end of the year as a deadline, which shouldn't be too hard to respect).
> 
> Do we agree on that ?

Re: [libxml++] Private members names

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

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


done.

- --

Christophe de Vienne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/lDwrHg4gmcYQS44RAiQFAKCQ2BbMHU29QVWd4UFsyEVzVYpaSwCgkUGD
xXOqR2QfRxvHa3V9qpK+D9w=
=xjBf
-----END PGP SIGNATURE-----

[libxml++] Private members names

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

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

Hi all,

I've prepared the patch to rename the private members with a trailing=20
underscore instead of a leading one.
I warn you before checking it in (I'll do it in in few days), if you have a=
ny=20
pending patch you want to apply before.

Cheers,

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

iD8DBQE/kZFrHg4gmcYQS44RAgHoAKCuLEQmisafcamUzl2Ax/XPqT8fuQCdGXu8
xWF9tOqX/Lrwhtj+L+2oACM=3D
=3DtGW4
=2D----END PGP SIGNATURE-----

[libxml++] Libxml++ docs for extreme beginner with XML libs

[Paulo J. de O. C. de M. <po...@me...>]

Hi all,

I need to write an application that saves and reads XML files in C++ but
I've never used libxml or libxml++. I've seen the docs of libxml++
generated by doxygen but that doesn't help me much since I would need
code examples, tutorials, etc.

Any ideas where I can find that?

Best regards,
--=20

Paulo J. Matos : po...@me...
Instituto Superior Tecnico - Lisbon
Computer and Software Eng. - A.I.
 - > http://mega.ist.utl.pt/~pocm
---
        -> God had a deadline...
                So, he wrote it all in Lisp!

[libxml++] Re: configure problem

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

Joel Schuster wrote:

>Hey there. I'm trying to build xmllib++ on a MinGW/MSYS system. The
>configure is not finding the xmllib2 stuff that it needs. Not really
>supprising, but I'm wondering how to tell configure where they are. I've
>downloaded the binary distribution of xmllib2.
>
>- Joel
>
>  
>

Hi,

You should use the mailing-list and not the admin adress, you'd get 
quicker answer :-)

However, to detect libxml, pkg-config is used. All you have to do is 
having a working pkg-config, which knows about libxml2.

Cheers,

Christophe

RE: [libxml++] write_to_stream speed

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

> The best advice for improving IOStream performance is to only use C++
> I/O (don't mix it with C stdio I/O) and unsynchronise the C and C++ I/O
> libs.

Investigating this for my project,
suspect that C++ locales may be 
a big performance hog.

Re: [libxml++] write_to_stream speed

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

On Tue, Sep 30, 2003 at 09:33:17PM +0200, Christophe de VIENNE wrote:

> Le Mardi 30 Septembre 2003 19:58, Jonathan Wakely a écrit :
> > On Sun, Sep 28, 2003 at 11:33:55PM +0200, Christophe de Vienne wrote:
> > > I've made small tests with write_to_stream and write_to_string.
> > > It appeared that using write_to_stream is _much_ slower than
> > > write_to_string then sending the result to the stream, even if using a
> > > ostringstream instead of std::cout.
> >
> > This *might* be because write_to_string followed by one call to
> > operator<<(ostream,string) can use the length of the string and perform
> > a single write, whereas write_to_stream will perform several writes to
> > the output location (whether it's a stringstream's buffer or stdout).
> 
> I was thinking of something like this.
> Do you know if there is any way to change how a ostream buffer or not the 
> datas before sending them ?

The best advice for improving IOStream performance is to only use C++
I/O (don't mix it with C stdio I/O) and unsynchronise the C and C++ I/O
libs. Before doing any I/O using C++ IOStreams call:

    std::ios::sync_with_stdio(false);

c.f. http://gcc.gnu.org/onlinedocs/libstdc++/27_io/howto.html#8

Also, if you're reading data from std::cin non-interactively and writing
to std::cout you might speed up the writes by untying cin and cout:

    std::cin.tie(0);

Without this every time you read from std::cin std::cout.flush() will be
called. This will only affect some programs (e.g. it has no effect if
you read from an ifstream not from std::cin).

How to do more than that and change the buffering is implementation-defined.
For GCC you can make an fstream use a different sized buffer like this:

    char buffer[4096];
    std::ofstream f;
    f.rdbuf()->pubsetbuf(buffer, sizeof(buffer));

I'm not sure if this works on std::cout because I cant remember whether
it's derived from std::ofstream in GCC 3.x

Of course none of this will make any difference when writing to an
ostringstream, as you can't change it's buffer size (it's one big,
variable-sized buffer that never writes anywhere) and it's not tied to
another stream. So maybe it's just GCC being slow  :-(

jon

-- 
IO ERIS IO ERIS ERIS

Re: [libxml++] write_to_stream speed

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

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

Le Mardi 30 Septembre 2003 19:58, Jonathan Wakely a =E9crit :
> On Sun, Sep 28, 2003 at 11:33:55PM +0200, Christophe de Vienne wrote:
> > I've made small tests with write_to_stream and write_to_string.
> > It appeared that using write_to_stream is _much_ slower than
> > write_to_string then sending the result to the stream, even if using a
> > ostringstream instead of std::cout.
>
> This *might* be because write_to_string followed by one call to
> operator<<(ostream,string) can use the length of the string and perform
> a single write, whereas write_to_stream will perform several writes to
> the output location (whether it's a stringstream's buffer or stdout).

I was thinking of something like this.
Do you know if there is any way to change how a ostream buffer or not the=20
datas before sending them ?

>
> Which compiler version did you test this with?
> There's been a *lot* of work on improving iostream performance in GCC
> recently, some of this won't land until GCC 3.4, but the 3.3.x branch
> has some improvements too.

gcc 3.3.x (I don't have the minor, but I think it's the last one).

Thanks,

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

iD8DBQE/edqOB+sU3TyOQjARAqBUAJ9iDcLbf2WeTcSKCbwmQH8f/CeuZQCgsU9X
8KXqS+SWVjZPb/4/qg515vg=3D
=3DM79e
=2D----END PGP SIGNATURE-----

Re: [libxml++] write_to_stream speed

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

On Sun, Sep 28, 2003 at 11:33:55PM +0200, Christophe de Vienne wrote:

> I've made small tests with write_to_stream and write_to_string.
> It appeared that using write_to_stream is _much_ slower than write_to_string 
> then sending the result to the stream, even if using a ostringstream instead 
> of std::cout.

This *might* be because write_to_string followed by one call to
operator<<(ostream,string) can use the length of the string and perform
a single write, whereas write_to_stream will perform several writes to
the output location (whether it's a stringstream's buffer or stdout).

Which compiler version did you test this with?
There's been a *lot* of work on improving iostream performance in GCC
recently, some of this won't land until GCC 3.4, but the 3.3.x branch
has some improvements too.

jon

-- 
"Any view of the universe that is not strange is false."
	- Neil Gaiman

Re: [libxml++] libxml++ future

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

On Mon, Sep 29, 2003 at 02:17:14PM -0400, Dan Dennedy wrote:

> > >  --it always goes back to that! So, I would need the SAX
> > > event exposed, and a very simple node subclass.
> > 
> > So I think a large part of this is: Adding 
> > class Entity : public Node
> > and telling libxml to give us Entities instead of substituting them. I
> > think there's some libxml function for that. (We should add the option
> > to libxml++ as well).

IIRC the libxml function is xmlSubstituteEntitiesDefault()
But I'm not sure it affects the SAX interface.

> I did some work over the weekend. I extended SaxParser with internal
> subset, entity declaration, and entity reference callbacks. In my parser
> implementation, I also implemented the getEntity callback and told
> SaxParser to use it, but I was curious about the difference between
> getEntity and reference. I was able to get everything working except for
> keeping entity references in tact

That was the main problem I found when looking at entity support in
SaxParser. I didn't find a way to do it that wasn't klugy and didn't
expose the raw libxml types.
I gave up after a brief struggle.

> --at least as far as xml serialization
> is concerned. I need to anaylze the resultant node tree further to see
> if content is a list of text and entity reference nodes. Either,
> libxml2, encodes entity references from "&ref;" to "&ref;" or I can
> set resolveEntities=1 in the libxml2 parser context to make it expand.
> The SAX reference callback is never called upon.

jon


-- 
"The tools we use have a profound (and devious!) influence on our
 thinking habits, and, therefore, on our thinking abilities."
	- Edsger Dijkstra

[libxml++] [ libxmlplusplus-Patches-815073 ] Prevent warnings from gcc -Wcast-qual

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

Patches item #815073, was opened at 2003-09-30 12:29
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=815073&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Wakely (redi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Prevent warnings from gcc -Wcast-qual

Initial Comment:
This patch changes some C-style casts to preserve

const-qualifications, so that GCC doesn' warn when the

-Wcast-qual switch is used.



Currently the return value of std::string::c_str()

(which has type const char*) is usually cast to

xmlChar*. This patch changes the cast to const xmlChar*

in these cases, and similarly for const xmlChar* to

char* conversions.



This is incomplete and only modifies three files. I'll

try to get round to the rest eventually.

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

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

Re: [libxml++] libxml++ future

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

On Fri, 2003-09-26 at 11:31, Christophe de VIENNE wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Le Vendredi 26 Septembre 2003 17:11, Dan Dennedy a écrit :
> > On Thu, 2003-09-25 at 18:42, Christophe de Vienne wrote:
> >
> > > Another possible thing is to wrap xmlInputBuffer. Although we can (and
> > > did) implement parse_stream without it, it would permit to implement
> > > xmlTextReader.getRemainder() in an elegant way (cf. 3).
> >
> > I think this is good, but I am also very interested in SAX
> > serialization, perhaps based upon one of node iterators below. I think
> > you can count on that conribution coming from me.
> >
> 
> I'm not familiar with this. Do you have any reference on it ?
> Thanks.

see the Component Pipelines section of
http://www.xml.com/lpt/a/2002/02/13/cocoon2.html

I think this is similar to what xmlsoft ML discussion and contributed
patch calls "inverted SAX." I don't know if it has been accepted into
libxml2. It is a simple idea tho--traverse tree while synthesizing SAX
events.

> >
> > I am also personally interested in entity-support in the near term.
> >
> 
> Well, this is not so evident thing to handle (cf. messages of DV on xml 
> mailing-list about SAX and entities).

hmm.. lots of reading to do here.

> What do you exactly need ?
> And do you have suggestions on how to do it ?

see response to murrayc

[libxml++] write_to_stream speed

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

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

Hi,

I've made small tests with write_to_stream and write_to_string.
It appeared that using write_to_stream is _much_ slower than write_to_strin=
g=20
then sending the result to the stream, even if using a ostringstream instea=
d=20
of std::cout.
I'll try to investigate this a bit more, to understand better those results=
,=20
and to see if something can be done at our level or not (I don't think so b=
ut=20
we never know).

Cheers,

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

iD8DBQE/d1POB+sU3TyOQjARAlpCAKCYyMef4tnSYTC7Lg4WB0Fk8xs87gCgk0du
YSQclGmK2VFJsR60pFC8nGY=3D
=3DXvmq
=2D----END PGP SIGNATURE-----

Re: [libxml++] libxml++ future

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

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

Le Vendredi 26 Septembre 2003 17:11, Dan Dennedy a =E9crit :
> On Thu, 2003-09-25 at 18:42, Christophe de Vienne wrote:
>
> > Another possible thing is to wrap xmlInputBuffer. Although we can (and
> > did) implement parse_stream without it, it would permit to implement
> > xmlTextReader.getRemainder() in an elegant way (cf. 3).
>
> I think this is good, but I am also very interested in SAX
> serialization, perhaps based upon one of node iterators below. I think
> you can count on that conribution coming from me.
>

I'm not familiar with this. Do you have any reference on it ?
Thanks.

>
> I am also personally interested in entity-support in the near term.
>

Well, this is not so evident thing to handle (cf. messages of DV on xml=20
mailing-list about SAX and entities).
What do you exactly need ?
And do you have suggestions on how to do it ?


Cheers,

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

iD8DBQE/dFvQB+sU3TyOQjARAlEfAKDKMHJXzzKHcN7XYz6LVnvcUKb7dQCgyz4G
VixyhIa7wmMwjnSs4USiSIk=3D
=3DJxMA
=2D----END PGP SIGNATURE-----

Re: [libxml++] libxml++ future

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

On Thu, 2003-09-25 at 18:42, Christophe de Vienne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> Here are a few features or little technical points I'd like to see in libxml++ 
> one day. Some could be included in the 1.0 version, while others will 
> certainly wait for a 1.2.
> 
> I would appreciate you to comment them : do you think it worth it having such 
> feature, and do you think it is a good technical choice.
> 
> I may have forgot some things important for you, don't hesitate to suggest 
> them.
> 
> - From you observations I will make a first RoadMap.
> 
> *******************************************************************************
> 1 - postfix private members intead of prefixing them with an underscore
> 
> target version : 1.0
> 
> The ISO c++ standart reserve names with a leading underscore to the 
> implemention. One shouldn't use some.
> Although there is no risk of real problem with that, I think it would be 
> cleaner.
> 
> *******************************************************************************
> 2 - wrap xmlIO.
> 
> target version : 1.0
> 
> xmlIO interface allow the creation of our own Input/Output Buffers. Wrap them 
> is an elegant and efficient way to reduce some useless potentialy big strings 
> copy.
> 
> Think about how to send a document to a stream. Currently we have to do :
> 
> std::ostream & output = std::cout; // could be any ostream of course
> std::string tmp = document.write_to_string();
> output << tmp;
> 
> In the above code, the entire document is written to a buffer by libxml, then 
> copied to a std::string by libxml++ which is finally returned by 
> write_to_string(). Even the a COW implementation of std::string, we'll need 
> twice more memory than the size of the document. With a non-COW 
> implementation it is even worse : it may be copied 3 or 4 time.
> 
> I wrote a small wrapper to xmlOutputBuffer and implemented a 
> Document::write_to_stream() function. The precedent code become :
> 
> std::ostream & output = std::cout; // std::cout is still an example of course
> document.write_to_stream(output);
> 
> The advantage is much more than just writing 1 line instead of 2. The entire 
> document is never in memory. libxml write to buffer by small pieces which are 
> immediatly sent to the stream by the wrapper. A patch demonstrating this is 
> on the patch manager if you want to experiment it. The wrapper allow the user 
> to very easily define it's own OutputBuffer. I modified dom_build example to 
> test it, and it works pretty well.
> 
> Another possible thing is to wrap xmlInputBuffer. Although we can (and did) 
> implement parse_stream without it, it would permit to implement 
> xmlTextReader.getRemainder() in an elegant way (cf. 3).
> 

I think this is good, but I am also very interested in SAX
serialization, perhaps based upon one of node iterators below. I think
you can count on that conribution coming from me.

-----

I am also personally interested in entity-support in the near term.

[libxml++] Document interface

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

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

Hi,

While working on Document, I was wondering why the write_to_xxx functions a=
re=20
virtual. I don't think this is needed.
Unless someone has some arguments against, I want to removed the virtual.
Any comment ?

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

iD8DBQE/dD0tB+sU3TyOQjARAoHhAKCX/lLHOQR4TG2cUIBBKMc0WERxhgCgjuij
NalgB3fc8PfksZR97AsshPY=3D
=3Dgqyo
=2D----END PGP SIGNATURE-----

Re: [libxml++] libxml++ future - strings and overloaded helper functions

[Matt E. <ma...@au...>]

Looks great!  A couple ideas I would be will to submit patches for
a)   Support of std::stringw in addition to std::string

b) Overloaded element functions which do conversions from primitives  
to strings for the caller
for example:
int n;
elem->add_content(n);

If people don't like b maybe an overloaded class which supports the 
function overloads..

BTW I am able to successfully able to use libxml++ on Linux, MacOSX, 
and win32 nice work!

On Thursday, September 25, 2003, at 03:42  PM, Christophe de Vienne 
wrote:

> Instead, we would explicitely instanciate the template classes into the
> dynamic lib with a chosen string type (very probably Glib::ustring). 
> Programs
> using this default string type wouldn't need to be recompiled at each 
> minor
> release, which is the main argument against templates.
> At the same time, users who want to use another string type (QString 
> for
> exemple, or even std::string of char *), could still do it, at the 
> price of
> recompiling their application at each release of libxml++, even if the 
> API
> doesn't change.
>
> - - Is this solution acceptable for you ?
> - - Is there any issue about LGPL with template libraries ?

[libxml++] libxml++ future

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

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

Hi all,

Here are a few features or little technical points I'd like to see in libxm=
l++=20
one day. Some could be included in the 1.0 version, while others will=20
certainly wait for a 1.2.

I would appreciate you to comment them : do you think it worth it having su=
ch=20
feature, and do you think it is a good technical choice.

I may have forgot some things important for you, don't hesitate to suggest=
=20
them.

=2D From you observations I will make a first RoadMap.

***************************************************************************=
****
1 - postfix private members intead of prefixing them with an underscore

target version : 1.0

The ISO c++ standart reserve names with a leading underscore to the=20
implemention. One shouldn't use some.
Although there is no risk of real problem with that, I think it would be=20
cleaner.

***************************************************************************=
****
2 - wrap xmlIO.

target version : 1.0

xmlIO interface allow the creation of our own Input/Output Buffers. Wrap th=
em=20
is an elegant and efficient way to reduce some useless potentialy big strin=
gs=20
copy.

Think about how to send a document to a stream. Currently we have to do :

std::ostream & output =3D std::cout; // could be any ostream of course
std::string tmp =3D document.write_to_string();
output << tmp;

In the above code, the entire document is written to a buffer by libxml, th=
en=20
copied to a std::string by libxml++ which is finally returned by=20
write_to_string(). Even the a COW implementation of std::string, we'll need=
=20
twice more memory than the size of the document. With a non-COW=20
implementation it is even worse : it may be copied 3 or 4 time.

I wrote a small wrapper to xmlOutputBuffer and implemented a=20
Document::write_to_stream() function. The precedent code become :

std::ostream & output =3D std::cout; // std::cout is still an example of co=
urse
document.write_to_stream(output);

The advantage is much more than just writing 1 line instead of 2. The entir=
e=20
document is never in memory. libxml write to buffer by small pieces which a=
re=20
immediatly sent to the stream by the wrapper. A patch demonstrating this is=
=20
on the patch manager if you want to experiment it. The wrapper allow the us=
er=20
to very easily define it's own OutputBuffer. I modified dom_build example t=
o=20
test it, and it works pretty well.

Another possible thing is to wrap xmlInputBuffer. Although we can (and did)=
=20
implement parse_stream without it, it would permit to implement=20
xmlTextReader.getRemainder() in an elegant way (cf. 3).

***************************************************************************=
****
3 - wrap xmlTextReader

target version : 1.0 ?

=46irst some reference if you want to know better what I'm speaking about :
* libxml2 xmlTextReader implementation :
http://xmlsoft.org/xmlreader.html
* C# xmlTextReader interface :
http://dotgnu.org/pnetlib-doc/System/Xml/XmlTextReader.html

I know this interface is not part the XML specification, which is one argum=
ent=20
not to implement it.
However I think is worth it : It will answer some needs on which SAX or DOM=
=20
are not satisfying for many people, and I bet some new users may get=20
interested into libxml++ if we implement such a thing.

I think we can give it an API very close to the C# one, thanks to the xmlIO=
=20
wrappers.

***************************************************************************=
****
4 - wrap xmlTextWriter

target version : it's too early to know

This interface if far less advanced than xmlTextReader. I don't think it's=
=20
time to think seriously about it but it's a logical step after xmlTextReade=
r.=20
An idea to keep for the future ?

***************************************************************************=
****
5 - use a string type which handle UTF-8

target version : 1.2

This point has been discussed in the past. I will just sum-up the state of =
the=20
discussions at this time.
The main debate was : do we impose a precise class or do we transform libxm=
l++=20
to a templated library to let the user which class he wants.
This debate ended with a vote pro/against templates with a quite balanced=20
result.

We however have an alternative way : explicit instanciation. This would=20
consist of implementing the lib with templates, but not including=20
implementations in header.
Instead, we would explicitely instanciate the template classes into the=20
dynamic lib with a chosen string type (very probably Glib::ustring). Progra=
ms=20
using this default string type wouldn't need to be recompiled at each minor=
=20
release, which is the main argument against templates.
At the same time, users who want to use another string type (QString for=20
exemple, or even std::string of char *), could still do it, at the price of=
=20
recompiling their application at each release of libxml++, even if the API=
=20
doesn't change.

=2D - Is this solution acceptable for you ?
=2D - Is there any issue about LGPL with template libraries ?

***************************************************************************=
****
6 - Implement node iterators

target version : ?

This point was also discussed earlier. We couldn't make any decision on a=20
clean API.
Since xmlNode has some internal pointers to the other nodes of the tree (ne=
xt,=20
prev, children, parent), we could easily implement iterators allowing to wa=
lk=20
in the tree in different ways :

=2D - children_iterator: explore all the children of a node.
=2D - depth_first_traversal_iterator: allow to explore all node with a dept=
h first=20
algorithm, starting from a node, ending when all the subtree has been=20
explored.
=2D - breadth_first_traversal_iterator: idem but breadth first.

These iterators could be bidirectionnal. The question is how to define the=
=20
end() element.
Each of them would have a const version.
I'll try to make something more complete than last time about this. Any ide=
a=20
is welcome.=09


***************************************************************************=
****
7 - make a better XPath support

target version : ?

I'm not very familiar with XPath. I don't know if the current support we ha=
ve=20
is enough for common uses. Any feedback on this would be appreciated.



***************************************************************************=
****
The end.

If you reached this point, thank you for reading :-)

I'm waiting forward for comments/ideas,


Best regards,

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

iD8DBQE/c29lB+sU3TyOQjARAiNkAJ4nk/xRLfksbrQ7MVxQoYHQ2nQRsQCdEwpO
ssdIu42Eu/5e0iqj2nSnWYg=3D
=3DLCLJ
=2D----END PGP SIGNATURE-----

[libxml++] [ libxmlplusplus-Patches-812758 ] wrap xmlOutputBuffer to implement Document.write_to_stream

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

Patches item #812758, was opened at 2003-09-26 00:02
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=812758&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christophe de Vienne (cdevienne)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrap xmlOutputBuffer to implement Document.write_to_stream

Initial Comment:
This patch is a demonstration of what a OutputBuffer 
wrapper could do. 
It need review and wouldn't be commited in in this 
state but it works. 

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

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

Re: [libxml++] [ libxmlplusplus-Patches-810606 ] Element::add_comment()

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

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

Le Lundi 22 Septembre 2003 15:51, Dan Dennedy a =E9crit :
> On Mon, 2003-09-22 at 09:44, SourceForge.net wrote:
> > +CommentNode* Element::add_comment(const std::string&
> > content)
> > +{
> > +  if(cobj()->type =3D=3D XML_ELEMENT_NODE)
>
> this test is not necessary
>
>

OK. I'll look at this and will probably include it in the release.

Cheers,

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

iD8DBQE/bwMLB+sU3TyOQjARAui0AJsHoxHPHoI3zslVYBM/tnJMujwYYwCfcfB+
6LohNKaDkHyWFYfYpFRAaz8=3D
=3DiCp3
=2D----END PGP SIGNATURE-----

Re: [libxml++] [ libxmlplusplus-Patches-810606 ] Element::add_comment()

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

On Mon, 2003-09-22 at 09:44, SourceForge.net wrote:
> +CommentNode* Element::add_comment(const std::string&
> content)
> +{
> +  if(cobj()->type == XML_ELEMENT_NODE)

this test is not necessary