libxml3 brainstorming (was: [xml] XML library evaluation (fwd))

["Peter Jacobi" <pj walter-graphtek com>]

Hi Daniel, All, C++-users, C++-haters, etc..

> > I'd hate to see it overlooked because of our own misuse of it. Hopefully
> > the information you've provided so far will be of some use to us (and
> > anyone else wishing to integrate libxml2 with C++ code).
>
>   Now if I could get a unified single C++ binding agreed upon by every C++
> users that may help too, but this looks unprobable...

IMHO there is some impedance mismatch between typical (idiomatic) 
use of C++ and libxml2. libxml2 not to blame, as it was no design goal 
AFAIK. This seems the be the reasons, that different C++ bindings exist 
and that it is sometimes assumed not to work at all.

Changes to this situation are a design goal for libxml3, I hope. 

I'm tempted to start the libxml3 requirements brainstorming, but given 
that I can spend only a coffee break on this, I apologize in advance for all 
errors. Also, even as it can be read as a wishlist for Santa Claus, I'm well 
aware that Santa Claus isn't coding for us.

** functionality
- validating (DTD, W3C Schema, Relax NG) with or without tree building

** API
- streamlining the API to reduce the number of entries
- making libxml internal structures internal by using them as opaque 
handles and provide accessors
- systematically return error codes (as return values or last parameter) 
which will be mapped to exceptions in C++ (and other) bindings
- the "non-mutating" (see below) requirement will change the signatures 
of many API entries. Old signature API can be provided as an 
compatibility layer

** inner workings
- eliminate the globals
- make memory management and other tuning per context
- pluggable tree implementations (optimization for read-only tree access, 
i.e. the usage pattern: parse to tree - ask the tree something or a lot - 
deallocate the entire tree). Maybe use of C++ STL containers for C++ 
bound libxml3
- make logically non-mutating access physically non-mutating and free of 
memory allocation, i.e. read access should never raise an exception, 
mean return an out-of-memry
- size and speed: recent discussions on ietf-xml-use imc org 
mentioned, "current XML parsers are within tens of K and operator at IO-
speed". This would be a worthwhile goal for embedded applications and -
for embedded x86- imply an improvement by a factor of three in size and 
speed of a mininal libxml3 build.

Regards,
Peter Jacobi