I hope you'll reconsider. I think having a student build another back end or two and work on polishing the interface would make a pretty good summer project.
Hmm, that does indeed sound like a good idea. How can we phrase that to be productive, though ?
What I would certainly support (and mentor) is a project where another XML "backend" is provided next to libxml2, and by doing this helping us make sure the (prospective) boost.xml API is indeed robust enough for such a switch (similar to boost.mpi, perhaps).
I think that Apache's xerces would make a good second such target. MSXML would probably be a better option. Expat... Maybe. I think that the project depends on the interface that you want to expose. I'd like to see a uniform method for opening XML files (preparing them to be parsed?), opening buffers for parsing, saving files?, etc. I'm guessing that a SAX-based interface wouldn't be too hard. I can't imagine that SAX providers don't expose wildly different APIs. How does this sound ? Is there any interest in this ? Such an endeavor may
also help rebut some of the arguments against the current approach, and thus help move us further towards an acceptable and official solution.
Well, I'm interested :) I think designing by the committee is the wrong way to go these libraries (XML, BigInt, etc.). I say wrap up the stuff that's out there and figure out where the problems come as we go. Nothing's ever perfect the first time you do it, and this isn't one of those times where it needs to be. Andrew Sutton andrew.n.sutton@gmail.com