I had a similar problem where I wrote an application for a client who also
wanted to compare the performance between various DOM parsers, including
Xerces-C and MSXML COM. The problem is that the interfaces are quite
different (mainly because there isn't an official COM idl yet). MSXML uses
'out' parameters while Xerces-C uses return values. There are different
initializations for getting to the document also. So, I wrote a pure
virtual base class with methods that conform EXACTLY to the DOM
specification. That became the API to my test app. Then I derived a class
from that base class for each different parser I was testing that wrapped
the calls to that parser. Worked pretty slick, but it is a little bit of
work to wrap up the parser APIs.
You could do something similar with only having to wrap the Xerces-C parser.
p.s. I can think of one good reason to wrap up a DOM API. If you switch to
a different parser later on, you can plug it in fairly easy to your apps and
hopefully, won't require any code changes to your apps. This is the main
concept behind layering and can be very handy for remote distributions and
compatible upgrades.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
