Alan, thank you for your interesting points. The API I suggest is not modeled after the the W3C DOM IDL, neither its java implementation. Many people have expressed discomfort both with the W3C DOM API as well as the idea of simply transcribing the java API to C++. Therefor, the API I suggest here is (so I hope) as C++-like as it can be, while still giving full flexibility to operate on (i.e. inspect as well as modify) XML documents. From the little I could gather about the alternatives you mention, it sounds like they would make very nice access layers on top of the base API (axis-oriented iterators, say).
I'd suggest, in any language wide implementation of XML, to attempt to separate transformation and query, from update. They are two very different applications.
I'm not sure I understand what you mean by transformation. How is it different from update ? Or is the former simply a (coarse-grained) special case of the latter, using a particular language to express the mapping (such as xslt) ?
I'd suggest starting with supporting XML documents that conform to the XPath and Query data model, and working backwards as the need arises. It makes for a much more consice library, and removes a lot of methods for rarely needed, often pathalogical, mutations.
There are clearly very different use cases to be considered. We should collect them and try to make sure that all of them can be expressed in a concise way. I'm not sure all of them operate on the same API layer. The code I posted supports xpath queries. While the result of an xpath query can have different types, right now only node-sets are supported (May be boost::variant would be good to describe all of the possible types). I'm not quite sure I understand what you mean by 'XPath data model'.
Implementing an object model would be much easier, if you ipmlement the 95% that is most frequently used. And if you sepearate the compexity of document mutation from the realative simplicity of iteration and transformation.
Could you show an example of both, what you consider (overly) complex as well as simple ? While the API in my code is certainly not complete (namespaces are missing, notably), I find it quite simple and intuitive. I don't think it needs to become more much complex to be complete. In particular, I'm hoping that we can make the API modular, so document access and document validation are kept separate (for example). May be that is what you mean, I'm not sure. Regards, Stefan