libxmlplusplus-general — Open discusions about libXML++

Re: [libxml++] Vote: templates everywhere v. Glib::ustring

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

B

Re: [libxml++] Vote: templates everywhere v. Glib::ustring

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

B

Re: [libxml++] templates v. library

[Elizabeth B. <li...@so...>]

   I used libxml2 recently in a C++ project and dealt with the
encoding issue by converting the original encoding to US-ASCII via
iconv.

   Perhaps something similar could be implemented in libxml++ such as
the constructor requiring an encoding (such as US-ASCII or UTF8),
which causes the orginial object to acquire an iconv_t token (see
iconv_open(3)). Each request for a string would then be run through
iconv using the above token.

   Elizabeth

Re: [libxml++] UTF8 support

[Ole L. <ol...@ha...>]

Stefan Seefeld <se...@sy...> writes:

> Ole Laursen wrote:
> 
> >>Please don't abuse std::string in such a horrible way.
> > You are exaggerating, really.
> > Remember that many string algorithms can be used without any trouble
> > if the std::string contains UTF-8. Copying, concatenation and even
> > replacement (of ASCII characters) all work.
> 
> No, replacement will *not* work, precisely because there is no simple
> mapping of 'character' to 'byte'.

Replacement of ASCII characters?

> > That covers 95%-100% of
> > the cases for typical GUI usage, I think.
> 
> I don't know how you come up with these numbers, and what you mean
> by 'typical'. As soon as you get into non-ascii regions you'll be
> in deep trouble.

std::string is useless if you're programming a GUI library. But my
point is that if you is just using one, as an application programmer,
most of the time you'll be copying complete strings back and forth,
perhaps doing some concatenations or replacing a few ASCII strings in
the interest of good i18n. That's what my experience tells my. You
seldomly need to consider individual characters.

Of course, if you do, you must find yourself a proper UTF-8 string.

For the Jabber client I'm writing, I use std::string for the back-end
library which uses libxml, and Glib::ustring for everything above that
in the hierarchy, including the GUI. It works fine - the XML parsing
is really a minor part of the program, and one that doesn't require
working with individual characters at all.

> You are ignoring my argument: the std::string API is completely
> inappropriate to deal with the utf8 encoding. All but data() and
> length() will cause undefined behavior.

Why? UTF-8 is not magic. Granted, it's a couple of years ago I studied
the subject, but if I understand the issue correctly UTF-8 simply
encodes ASCII characters as ASCII characters and all other characters
as a sequence of bytes with their two highest bit set, the first one
with some extra magic to distinguish it. So a Latin-1 character would
be two bytes like

   1101 1010   1010 1010
   ^^^         ^^
   high order bit magic

As long as you don't split these byte sequences, you're fine. That's
how I understand it, at least.

I even found a definition if you want the accurate explanation:

   In UTF-8, characters are encoded using sequences of 1 to 6 octets.
   The only octet of a "sequence" of one has the higher-order bit set to
   0, the remaining 7 bits being used to encode the character value. In
   a sequence of n octets, n>1, the initial octet has the n higher-order
   bits set to 1, followed by a bit set to 0.  The remaining bit(s) of
   that octet contain bits from the value of the character to be
   encoded.  The following octet(s) all have the higher-order bit set to
   1 and the following bit set to 0, leaving 6 bits in each to contain
   bits from the character to be encoded.

   [ftp://ftp.rfc-editor.org/in-notes/rfc2279.txt]

So there. :-)

I do apology if you already knew this, but your statement "All but
data() and length() will cause undefined behavior." leads me to
believe that perhaps you didn't.


I do agree that std::string is inappropriate as a UTF-8 "std::string".
But you can think of it as a UTF-8 byte string. Think about it. That's
what I meant when I compared std::string to 'char *'.

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/

Re: [Re: [Re: [Re: [libxml++] UTF8 support]]]

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

>
>
>>
>>Back to the point: I use this C++ wrapper in a couple of projects. I
>>don't want to deal with more than one if not absolutely necessary.
>>    
>>
>
>I have really made up my mind but at the moment I am slightly against this API
>change because:
>1. I don't think _many_ people want to use libxml++ with a pre-existing
>Unicode string class other than Glib::ustring. I do understand that you want
>to personally but it's still hard to know what people want in general. I would
>gladly hear from other people who want to use QString with libxml++, or some
>other class.
>
I'm not using unicode at the moment, but if I wan't to add it to my 
project later I don't want to be restricted
in my choice of unicode library by the interface of libxml++. I use 
neither Qt nor glib now, so I might choose
another unicode library.

>2. I'm not sure that it's worth giving up the benefits of libxml++ being a
>shared library just so that people don't have to write utility functions to
>convert from Glib::ustring to their own string classes. In particular I'm
>scared of asking people to recompile their apps just to get minor libxml++
>implementation fixes.
>
>Again, I haven't made up my mind. And again, I'm not sure. And because I'm not
>sure I might write this up again later and ask for a vote.
>
>Not that this, or the use of glibmm, would definitely go into the unstable
>branch only anyway.
>
>  
>
Of course, one shouldn't have to recompile applications when new minor 
stable versions are released.
But I think a new major version (1.0 or whatever comes next) should use 
templates.

Philipp Krause

[libxml++] Attn: Protect Your Computer,You Need Systemworks!

[<mar...@ly...>]

bGlieG1scGx1c3BsdXMtZ2VuZXJhbCwgUHJvdGVjdCBZb3VyIENvbXB1dGVy
IEZyb20gVW53YW50ZWQgQW5kIEhhemFyZG91cyBWaXJ1c2VzISENCg0KTm9y
dG9uIFN5c3RlbVdvcmtzIDIwMDMgU29mdHdhcmUgU3VpdGUgKFByb21vLUNW
NDM1UFcpDQoNCkFMTCBGSVZFIC0gRmVhdHVyZS1QYWNrZWQgVXRpbGl0aWVz
IEZvciBPbmx5ICQzOS45OQ0KDQohIC0gTm9ydG9uIEFudGlWaXJ1cyAyMDAz
CQ0KISAtIE5vcnRvbiBHaG9zdCAyMDAzDQohIC0gR29CYWNrIDMgUGVyc29u
YWwgRWRpdGlvbgkNCiEgLSBOb3J0b24gVXRpbGl0aWVzIDIwMDMNCiEgLSBO
b3J0b24gQ2xlYW5Td2VlcCAyMDAzDQoNCk9ubHkgJDM5Ljk5ISAoU2hpcHBp
bmcgaXMgaW5jbHVkZWQhKQ0KDQpPcmRlciBZb3VycyBUb2RheSEgDQpodHRw
Oi8vYW50aXZpcnVzbmV3cy5jb20vbnN3MzguaHRtP0FOVEl2aXJ1cz01dnFS
dzZ4DQoNCklmIHlvdSBkbyBub3Qgd2lzaCB0byByZWNlaXZlIGZ1cnRoZXIg
bWFpbGluZ3MsIHBsZWFzZSB2aXNpdCANCnRoZSBsaW5rIGJlbG93LiBXZSBo
b25vciBhbGwgcmVtb3ZhbCByZXF1ZXN0cy4gU3VibWl0IHlvdXIgcmVxdWVz
dCBhdDoNCmh0dHA6Ly9hbnRpdmlydXNuZXdzLmNvbS9nb29kYnllLmh0bWw/
aWQ9NzY4MTc0DQo0OTU1eEhHZzQtNTEzdWJzQTQ4MzR4cUx1MS00NjZrbDI5

Re: [Re: [libxml++] UTF8 support]

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

Hi Rasmus,

you are listing important requirements, which, however, apply only
partly the libxml++ (the other half applies to the unicode library).

Rasmus Kaj wrote:

>  1. The library should efficiently cope with any legal XML.

agreed.

>  2. I want to be able to get a std::string (with a specified encoding)
>     of a value.  Most of the XML I will handle will be ISO8859-15
>     (thats just me, but replace the encoding with other encodings and
>     a lot will be covered).

That is a requirement for the unicode lib: as libxml2 uses one 
particular encoding internally (utf8), which you want to be able to
'transcode' into another.

>  3. When necesarry, I want to be able to get a std::wstring (a
>     std::string of wide characters).  I want to be able to handle
>     individual characters in the string, and I want to use standard
>     C++.  Then this is the "correct" way of handling unicode strings.

that, too, is an issue the unicode library has to deal with:
I take it that with 'standard C++' you mean you want to be able to
access characters with the '[]' operator. That is a requirement for
the specific encoding you use. With utf8 characters don't have a fixed
size, so you don't have random access. Instead you have to iterate
over the string to find the nth character.

So, depending on what you want to do with the string, one encoding
may be better than another.

Please note that there is no way for  unicode to fit into std::wstring,
as that has >16 bit, while unicode needs 21 bits per character. Some
'planes' fit into these 16 bit, but for lots of characters you need
more, so the encoding becomes variably sized (meaning, as explained
above, there is no random access).

>  4. Sometimes, it would probably be nice to get utf8 data as well.

yep.

> The ordering of the points reflects their relative importance to me
> personally, but I believe the following conclusions to hold regardless
> of how the points are reordered:
> 
> Point one suggests that the library should use utf8 internally.  I
> don't care much how this is done, but some kind of refptr<char*> seems
> relatively sane while putting utf8 data in a std::string feels bad.

agreed.

> Points 2 - 4 suggests that the get_ / set_ string methods should be
> templated on string class and conversion method.  The alternative is
> that I would have to call a converter at every call to a get_ / set_
> string method, meaning in practice that I would have to write a
> wrapper around libxml++ (which would feel ridiculous, since libxml++
> itself is a wrapper around libxml).

agreed.

> Note that this _doesnt_ imply that the entire libxml++ would go from a
> "dynamic library" to a "template library".  Just that some of the
> methods would be templates.  Also, "common instatiations" of a
> template method can - at least threoreticlly - be included in a
> dynamic library.

well, most methods deal with strings. I originally tried to factor
out the string-type agnostic part into a base class, but that didn't
lead anywhere.

I agree that it would be possible to compile specific 'unicode bindings'
to deal with Murray's points about interface/implementation separation.
Whether that's actually worth the efford is another story.

Regards,
		Stefan

Re: [Re: [libxml++] UTF8 support]

[Rasmus K. <kaj@e.kth.se>]

This discussion seems to have gone a bit out of hand, but anyway,
here's my view of it.  These are the main features I want regarding
character conversion:

 1. The library should efficiently cope with any legal XML.

 2. I want to be able to get a std::string (with a specified encoding)
    of a value.  Most of the XML I will handle will be ISO8859-15
    (thats just me, but replace the encoding with other encodings and
    a lot will be covered).

 3. When necesarry, I want to be able to get a std::wstring (a
    std::string of wide characters).  I want to be able to handle
    individual characters in the string, and I want to use standard
    C++.  Then this is the "correct" way of handling unicode strings.

 4. Sometimes, it would probably be nice to get utf8 data as well.

The ordering of the points reflects their relative importance to me
personally, but I believe the following conclusions to hold regardless
of how the points are reordered:

Point one suggests that the library should use utf8 internally.  I
don't care much how this is done, but some kind of refptr<char*> seems
relatively sane while putting utf8 data in a std::string feels bad.

Points 2 - 4 suggests that the get_ / set_ string methods should be
templated on string class and conversion method.  The alternative is
that I would have to call a converter at every call to a get_ / set_
string method, meaning in practice that I would have to write a
wrapper around libxml++ (which would feel ridiculous, since libxml++
itself is a wrapper around libxml).


Note that this _doesnt_ imply that the entire libxml++ would go from a
"dynamic library" to a "template library".  Just that some of the
methods would be templates.  Also, "common instatiations" of a
template method can - at least threoreticlly - be included in a
dynamic library.


-- 
Rasmus Kaj ----------------------------------------------- ra...@ka...
 \ What is the word where la is the middle, is the beginning, and the end?
  \------------------------------------- http://www.stacken.kth.se/~kaj/

Re: [libxml++] UTF8 support

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

Ole Laursen wrote:

>>Please don't abuse std::string in such a horrible way.
> 
> 
> You are exaggerating, really.
> 
> Remember that many string algorithms can be used without any trouble
> if the std::string contains UTF-8. Copying, concatenation and even
> replacement (of ASCII characters) all work.

No, replacement will *not* work, precisely because there is no simple
mapping of 'character' to 'byte'.

> That covers 95%-100% of
> the cases for typical GUI usage, I think.

I don't know how you come up with these numbers, and what you mean
by 'typical'. As soon as you get into non-ascii regions you'll be
in deep trouble.

You are ignoring my argument: the std::string API is completely
inappropriate to deal with the utf8 encoding. All but data() and
length() will cause undefined behavior.

Stefan

Re: [libxml++] UTF8 support

[Ole L. <ol...@ha...>]

Stefan Seefeld <se...@sy...> writes:

> Ole Laursen wrote:
> 
> > But I really don't see the big problem here. std::string is really
> > just a fancy way of saying 'char *', right?
> 
> No.
>
> > And any decent
> > Unicode-aware string library will have a convenient conversion from
> > std::string, right?
> 
> No.

Then they are utterly broken IMNSHO. :-)

At least you should be able to do from_raw(my_string.data(),
my_string.size()).

[...]

> While it may be true that you can (technically) use std::string to
> contain utf8 data, the std::string *interface* would be completely
> inappropriate (beside the 'data()' and 'length()' methods :-)
> 
> Please don't abuse std::string in such a horrible way.

You are exaggerating, really.

Remember that many string algorithms can be used without any trouble
if the std::string contains UTF-8. Copying, concatenation and even
replacement (of ASCII characters) all work. That covers 95%-100% of
the cases for typical GUI usage, I think. I do have first hand
experience with this, combining Glib::ustring with legacy
std::strings.

Yes, it will be unsafe if you try to access certain parts of the
interface. But even it is crippled std::string, it is still much more
convenient than a 'char *'.

> But to go along the line you seem to suggest: libxml++ may use a
> 'data container' that is agnostic of the encoding or any related
> interpretation of the content. That may actually not even be such
> a bad idea, since it could just be a smart pointer taking over
> the memory from libxml2, freeing the data in its destructor using
> xmlFree().

Perhaps this idea is better. If there is an implicit
conversion to char*, it will interface nicely with both std::string
and Glib::ustring.

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/

Re: [libxml++] UTF8 support

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

Ole Laursen wrote:

> But I really don't see the big problem here. std::string is really
> just a fancy way of saying 'char *', right?

No.

> And any decent
> Unicode-aware string library will have a convenient conversion from
> std::string, right?

No.

> So if you need to process the individual characters (in my experience
> with gtkmm/glibmm, this is seldomly needed) you can simply treat the
> input/output from the library as raw data which you feed to your
> string library. Why is this a problem?

I don't fully get your point. Are you advocating libxml++ continuing
to use std::string ? That's really a bad idea IMO:

'char *' is, beside being used for strings in C, a data type used for
generic memory, i.e. there are no semantics associated with it (such
as 'null terminated string').

std::string represents *text*, and as such, it has a lot more meaning.
You can iterate over the elements, expecting to get at individual
characters. Just to name an example.

While it may be true that you can (technically) use std::string to
contain utf8 data, the std::string *interface* would be completely
inappropriate (beside the 'data()' and 'length()' methods :-)

Please don't abuse std::string in such a horrible way.

But to go along the line you seem to suggest: libxml++ may use a
'data container' that is agnostic of the encoding or any related
interpretation of the content. That may actually not even be such
a bad idea, since it could just be a smart pointer taking over
the memory from libxml2, freeing the data in its destructor using
xmlFree().
That would make it possible to abstract the unicode library away
as my suggestion, and would replace my suggested compile-time 
polymorphism by runtime-polymorphism (assuming appropriate
conversion functions doing the 'convert from/to libxml2' work).
It wouldn't incure much performance penalty, as there is no
additional copying involved.

Regards,
		Stefan

Re: [libxml++] WIN32 compilation

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

On Friday, February 21, 2003, at 02:11 AM, Martijn wrote:

> Does anyone know how to compile libxml++ on WIN32 platform?
>

I am using it with GCC 3.2 as a cross compiler. It was a pain to set 
up, but it worked quite well.

But now, all of the sudden, when I recompile libxml++ the DLL has no 
symbols. It had symbols yesterday. Argh! Sorry, random rant.

If you need some GCC 3.2 Win32 binaries, I can get them to you after I 
fix the above issue. (The version that I'm using is 0.18)


--- darco
http://www.deepdarc.com/

[libxml++] UTF8 support

[Martijn <roo...@xs...>]

Hi all,

Is there any planning regarding UTF8 support within the library?

regards,

Martijn.

Re: [libxml++] WIN32 compilation

[Martijn <roo...@xs...>]

Thanks Philipp,

I will give it a go!

----- Original Message -----
From: "Philipp Krause" <pk...@sp...>
To: <lib...@li...>
Sent: Friday, February 21, 2003 16:58
Subject: Re: [libxml++] WIN32 compilation


> Martijn wrote:
>
> > Does anyone know how to compile libxml++ on WIN32 platform?
> >
> > regards,
> >
> > Martijn.
> >
>
> I compiled libxml++ 0.18 with VC++ 6.0. I used the STLPort STL and
> had to fix the following bugs (which I already posted on this list):
>
> domparser.cc, line 71: getline should be changed to std::getline
> saxparser.cc, line 170: getline should be changed to std::getline
> domparser.cc, line 129: remove semicolon at end of line
> element.cc: In function write there are to variables both named iter,
> since they are declared in the for statement this is OK with the current
C++
> standard, but some compilers (like MSVC++) still follow the older version.
> Please rename them to unique names.
>
> I don't know if they are fixed in the current release.
>
> Philipp Krause
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
>

Re: [libxml++] WIN32 compilation

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

Martijn wrote:

> Does anyone know how to compile libxml++ on WIN32 platform?
>  
> regards,
>  
> Martijn.
>  

I compiled libxml++ 0.18 with VC++ 6.0. I used the STLPort STL and
had to fix the following bugs (which I already posted on this list):

domparser.cc, line 71: getline should be changed to std::getline
saxparser.cc, line 170: getline should be changed to std::getline
domparser.cc, line 129: remove semicolon at end of line
element.cc: In function write there are to variables both named iter,
since they are declared in the for statement this is OK with the current C++
standard, but some compilers (like MSVC++) still follow the older version.
Please rename them to unique names.

I don't know if they are fixed in the current release.

Philipp Krause

[libxml++] WIN32 compilation

[Martijn <roo...@xs...>]

Does anyone know how to compile libxml++ on WIN32 platform?

regards,

Martijn.

[libxml++] Reduce overhead of unhandled SAX events

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

G'day all, bit of a long one this, sorry ...

I've submitted a patch to SF that allows a derived SaxHandler to specify
which events to handle, so when the default libxml2 implementation is
suitable there is no additional overhead.

Currently each SAX event handled by the xmlpp::SaxParser class has an
overhead of calling the static callback function and the virtual handler
function.  If a user doesn't care about a particular event and doesn't
override the relevant virtual function they still pay the overhead for
the two functions, and then fall back to the libxml2 implementation.
This adds two function calls to the C library equivalent, only one of
which could be inlined in most cases (the non-virtual one). This goes
against the C++ philosophy of not paying for features you don't use
(and gives ammo to those who say C++ is inherently inefficient, grrr!)

This isn't a big deal at the moment, as the events that libxml++ can
handle are the common ones that most people will override in their
derived parser, but if more events were supported (e.g. entityDecl,
resolveEntity etc.) all users of the base class would have the
additional overhead for these events, despite the fact that the
libxml2 implementation is fine for most people.

The patch adds a protected constructor taking an xmlSAXHandler struct.
The new constructor initialises _sax_handler with the supplied struct,
allowing the derived class to specify which callbacks should be enabled
(for a derived class to do this the callbacks must be protected).  For
now all this does is let a derived class specify that certain events
shouldn't be handled, however as new events are supported by libxml++
and relevant callbacks and virtual functions added this extra ctor
becomes more useful.  The new handlers could be disabled by default, but
a derived class can enable them using the new ctor.  This allows you to 
provide handlers for every event supported by libxml2, with no
additional overhead for the events you don't use (actually, I think the
vtable will be slightly larger, so there's a slight space overhead for
each additional virtual function).

Alternatively, rather than adding new functions to the base class an
extended ExtSaxParser class could add new callbacks and virtuals to the
base class, and assign them to the xmlSAXHandler that is passed to the
base ctor. This would keep the base class simple, using subtypes for
extensions (although since there's no overhaed I'd prefer to extend the
base class by adding the functions there and disabling them by default)

The downside, as I see it, is that we're exposing implementation detail
by making the callback functions visible to derived classes.

All comments welcome,

jon


-- 
"If you can't say anything good about someone, sit right here by me."
	- Alice Roosevelt Longworth

Re: [libxml++] wrapper for the xmlreader interface

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

On Mon, Feb 17, 2003 at 05:26:16PM +0000, Edd Dumbill wrote:

> > My TextReader wrapper already converts xmlChar*s to std::string and
> > frees the xmlChar*. I think Edd's might implement slightly more of the
> > member functions (they weren't all available in libxml2 when I started).
> > I'll try to find time this week to look at Edd's properly and possibly
> > merge the two.
> 
> Yeek, I didn't realise somebody else had started doing this as well. 
> Yes let's get together and merge this work!

I'm afraid I haven't even looked at this yet, and will be away from
tomorrow until next tuesday, so I'll send my TextReader to the list this
evening so that if I don't get a chance to do anything at least you can
look at it and point out all the mistakes in my absence  ;-)

jon


-- 
"People who are willing to give up freedom for the sake of short term
 security, deserve neither freedom nor security."
	- Benjamin Franklin

[libxml++] new contexts code from CVS

[Edd D. <ed...@us...>]

Murray asked me to post this:

<murrayc> edd: Do me a favour. My email is down - Please post to
libxml++ telling people to try the new using-contexts code in cvs. It
should allow us to implement validation soon.

cheers,

-- Edd

Re: [libxml++] Node's xpath methods

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

Rasmus Kaj wrote:

> How about having a class XPath as a parameter to find, and an
> (explicit) constructor from std::string to XPath?  That way, one can
> write "mynode.find(XPath(my_xpath_string));" if one have a string.
> 
> Also, the XPath constructor could (in the future) actually parse the
> xpath, so that doesn't have to be done for every find().

agreed. Why would you make the XPath constructor explicit ?
I think it would be just fine to let the user specify
'find("foobar")' and not being aware of the implicit XPath object.


Regards,
		Stefan

Re: [libxml++] XML-based Configuration Wrapper

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

Paul Tan Hock Lai wrote:
> Hi,
> 
> I would like to create a xml-based file to persist the DHCP lease or configuration.

libxml++ is a library to parse xml data and manipulate dom-like
structures. XML itself is a 'meta language' in that it lets you define
domain-specific formats by means of 'document types'. It is up to you
to define your document vocabulary / structure and then implement
(possibly using libxml++) tools to manipulate these data.

Stefan

Re: [libxml++] XML-based Configuration Wrapper

[Paul T. H. L. <ta...@i2...>]

Hi,

I would like to create a xml-based file to persist the DHCP lease or =
configuration.

Cheers,
Paul

>>> se...@sy... 02/07/03 10:14PM >>>
Paul Tan Hock Lai wrote:

> I am looking for some XML-based configuration software that can perform =
configuration-specific :

can you elaborate a bit ? What exactly do you want the software to do ?

Stefan



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
http://www.vasoftware.com=20
_______________________________________________
Libxmlplusplus-general mailing list
Lib...@li...=20
https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general

[libxml++] Patch for libxml++ (was Re: Parsing streams of XML)

[Ole L. <ol...@ha...>]

Stefan Seefeld <se...@sy...> writes:

> Ole Laursen wrote:
> 
> > So each of these <message> and <presence> elements are small documents
> > in themselves. If I could get a DOM-representation of each of them, it
> > would somewhat easier I think. Any hints?
> 
> well, these chunks are not valid xml documents in themselfs, so you have
> to treat them as parts of a parent document. Libxml2 supports parsing of
> chunks, and I think what you are looking for is really an event driven
> approach, where your sax handler is called per tag that is encountered
> in the stream. Libxml++ doesn't provide chunk-wise parsing yet...

Well, if it has to be SAX, it has to be SAX. Anyway, making state
machines are fun, it's just the maintaining part I fear. :-)

However, the lack of chunk-wise parsing is a show-stopper. I can't
derive from SaxParser since all the sexy details are kept private.
What about extending the interface?

AFAICS, all it needs is:

  virtual void parse_chunk(const std::string& chunk) throw(exception);
  virtual void finish_chunk_parsing() throw(exception);

The contents of parse_chunk can be stolen almost verbatim from
parse_stream. I've put a small patch (with documentation and example)
here:

  http://www.cs.auc.dk/~olau/misc/libxml++.patch

Any chance of getting it in?

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/

[libxml++] Out of Office

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

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

Hi,

For personnal reasons I'll be out for at least a couple of week.

Murray, I let you make decisions on patches inclusions if needed. Thanks.

As far as the iterator stuffs, the NodeList type which is a Forward Container 
is ok for me, and I think a const container will be needed.

Best regards,

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

iD8DBQE+ShUdB+sU3TyOQjARAm8iAJsG0ePiI3+qwGy6iN7LTr3ruZairACfUfVF
2CDCIiXrnfhckjazjnE3fa8=
=rKQ0
-----END PGP SIGNATURE-----

Re: [libxml++] wrapper for the xmlreader interface

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

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

Hi,

Thanks for your contribution.

I personally cannot check your work for inclusion before a couple of week.
Could you provide the patch in the patch manager ?
I invite Murray to include your patch in the unstable branch when he thinks 
it's ready.

Cheers,

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

iD8DBQE+ShN4B+sU3TyOQjARAvLnAJ42bnWQc8TE4lCgnPhpH7Q7xQ9BzACgi3OJ
1mlMLlpeeB5ZPT+Pph79/dk=
=b4qR
-----END PGP SIGNATURE-----