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

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.

Peter Jacobi

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]