This is a good topic actually. The XSLT processor currently in the extensions package of Mozilla was written by myself. It uses a C++ DOM written by one of my ex-colleagues when I was working for MITRE and it uses the Expat XML parser from James clark. Mozilla also has it's own DOM implementaion. It would be great if we could standardize on a simple set of interfaces that would make some compatibilty across the DOM implementations easier like it is in Java.
I will be porting the Java classes for the serializer package to C++, the SAX will be pretty straight forward, but the DOM printer will currently have to be tied to a specific implementation. I think it would be nice to define, as light as possible, the set of purely virtual class that all C++ DOM implementions should implement. --Keith [EMAIL PROTECTED] wrote: > >>However, it's worth pointing out that you may wind up wanting to make > >>multiple implementations of the DOM available, tuned for different > >>purposes. You may or may not want to consider that when picking your > >>package name. > > And that brings out another issue: we lack an abstract DOM in C++. The > org.w3c.dom.Node, etc. Java classes are interfaces, so you can at least > imagine having several tuned implementations. But the C++ dom\DOM_Node > class is a non-abstract, non-polymorphic wrapper of NodeImpl. I think it > would be grand if we had a set of abstract base classes for DOM_Node, etc. > Would this cause an especially bad performance hit, adding a vtable to each > node?
