Update September 10, 2009: With CMarkup release 11.2, during compile CMarkupMSXML imports the MSXML interface from msxml6.dll (since release 10.1 it defaulted to msxml3.dll, before that msxml.dll). If you would rather build your project using MSXML 3.0, define MARKUP_MSXML3.
Update December 17, 2008: With CMarkup release 10.1, CMarkupMSXML will dynamically load the MSXML component available on the machine, it will try MSXML 6.0, then 3.0, then 4.0 then 5.0. That is, unless you compile with MARKUP_MSXML1 defined, in which case it will compile for MSXML 1.0 and load MSXML 1.0 only.
You need at least MSXML 3.0 for XPath, XSLT transformation and XML Schema validation.
The primary differences between MSXML 1.0 and MSXML 3.0 compiling (see #if defined(MARKUP_MSXML1)) are in the CreateInstance identifier and the MSXML2 namespace. The MSXML3 version now exposes the m_pDOMDoc as an IXMLDOMDocument2 object. (You'll notice the number 2 in this interface version and the namespace is just a byproduct of changes in the C++ MSXML SDK and is not to be confused with the MSXML version.)
See also:
Most machines with recent Windows operating systems and Internet Explorer will have MSXML 3.0 so that you can compile. If it does not work, make sure you have msxml3.dll in your System32 folder. The latest MSXML toolkit can be downloaded from MSDN.
Although I had msxml3.dll on my NT box for over a year, I discovered it was not registered properly. My MSXML toolkit download contains xmlinst.exe which I unzipped in C:\TEMP and I did the following from the DOS prompt:
C:\TEMP>xmlinst (scanning process table for use of msxml*.dll) Error while looking for msxml3.dll registry entries! C:\TEMP>xmlinst -u (scanning process table for use of msxml*.dll) removed old & new dll entries C:\TEMP>cd \winnt\system32 C:\WINNT\system32>regsvr32 msxml3.dll C:\WINNT\system32>cd \temp C:\TEMP>xmlinst (scanning process table for use of msxml*.dll) using "%SystemRoot%\system32\msxml3.dll"... removed old dll entries registered dll for old registry entries.
Update June 11, 2005: I tried compiling the MSXML 3.0 build of CMarkupMSXML on a new machine with VC++ 6.0 and ran into compiler errors something like this: (not sure if it was msxml3.tli or msxml4.tli)
msxml4.tli(49) : error C2143: syntax error : missing ';' before 'tag::id'
msxml4.tli(49) : error C2433: 'DOMNodeType' : 'inline' not permitted on data declarations
msxml4.tli(49) : error C2501: 'DOMNodeType' : missing storage-class or type specifiers
msxml4.tli(49) : fatal error C1004: unexpected end of file found
These errors do not appear if instead of using CMarkupMSXML you only have #import "msxml3.dll" and a limited usage of MSXML code. I have not yet researched into the exact combinations of calls and usages that bring about these errors, but I had also run into this problem importing MSXML 4.0 and temporarily included msxml2.h to get around it. There are some postings online discussing this error which they say is due to a difference between MSXML3 file version 8.3 and 8.5 but no solution was given. However, Microsoft Knowledge Base Article 832688 describes what seems to be a relevant problem and gives a solution that works. Simply add the undocumented no_function_mapping compiler directive to your #import statement as follows:
#import <msxml3.dll> no_function_mapping
Skimming the article, it says "the Microsoft Visual C++ compiler inserts the implementation_key compiler directive in the TypeLib Information [TLI file]... to improve performance... and you may receive the compiler errors... This behavior is by design."
So no_function_mapping removes the #pragma implementation_key directives from the TLI file and the compiler errors go away. I am left a little uncertain about two things. First of all, I assume the performance they are speaking of is only for the compiler, not the program runtime. Secondly, labeling it "behavior by design" leaves a lot to be desired. It is not clear whether this is a problem in our case with implementation_key side effects, or the way the compiler "injects" the implementation_key directives, or the way the specific version of MSXML 3.0 leads these directives to be generated.