Jon Radoff wrote :
b) Those that are complete have very annoying and/or intractable dependencies. Examples: Libxml++ is simply a beast to build (lots of GNOME/Glib dependencies, and it produces compiler errors on MSVC that are left to the implementor to fix);
That's because libxml++ wanted to use a special string type for unicode that was available in glibmm (glib C++ wrapper). You can disable this though and handle the utf-8 through std::string, which removes the dependencies, and probably the building problems with older MSVC versions. (current versions of gtkmm/glibmm are known to support MSVC8 only) I think using such a string type is a good idea though, but something available as a self-supporting library would be better.
3) I think DOM support is critical. There's ample C++ libraries and wrappers for doing non-DOM XML manipulations, but there doesn't seem to be adequate options for good DOM libraries. It seems to me that if the library implementor doesn't tackle the challenge of making a nice C++ DOM class interface, then I'm left with the impression that boost wouldn't really be adding anything new to the world.
While DOM is memory consuming, it's still the simplest way I can think of to edit an existing XML document. Moreoever it is the standard API. So of course supporting it is very important.