Phil Endecott wrote:
As far as I can see, what you have is a wrapper around the GNOME libxml2 (which has an MIT-license and is cross-platform) that implements something that you call dom, but is not the standardised "DOM" API for XML (http://www.w3.org/DOM/).
Right. The "DOM" API isn't actually standardized for anything but Java. So in my attempt to provide a "DOM-like" API I have been trying to capture the semantics, not the syntax, and map that to "modern C++ style" idioms. To me, DOM stands for an API that allows in-memory manipulation of, well, structured documents. That includes full (generic) tree traversal, as well as XML-specific operations, such as XPath-based node lookup, validation, as well as other domain-specific operations. Finally, it is important to keep a balance between encapsulation and transparency. While it is true that, semantically at least, one could map some of the helpers by STL (or boost, for that matter) types, I deliberately refrained from such an approach, to allow existing implementations to be bound to the API. In particular, I'm using here libxml2 as backend, which has been fine-tuned for best performance over a couple of years. I'm not courageous / naive enough to attempt to match such an implementation with a new one. Instead, I want a seamless mapping that doesn't impose any unnecessary copying or other indirection to mitigate the 'impedance mismatch'. I will try to write my thoughts and design rationales up in a document, so things become a little clearer. Thanks for your comments ! Stefan -- ...ich hab' noch einen Koffer in Berlin...