Working with an XML document using the MSXML parser

In recent articles on XML and MSXML DOM parsers in Kenn Scribner, only some of the features of the parser are described. These articles describe XML as a technology, but do not introduce the XML parser itself. Now, Kenn will go back to the MSXML parser and explain the basics of working with XML documents and nodes: Searching for specific nodes, inserting nodes, and retrieving node values.

The MSXML parser is based on the XML Document Object model and is important for viewing the various document objects shown in table 1. These objects are directly derived from the XML specification itself. MSXML can also merge XML DOM objects into COM further. Therefore, it is easy to figure out which XML DOM object corresponds to which MSXML COM interface. For example, IXMLDOMNode represents a DOM object called Node.

Table 1. XML DOM objects and their purpose
DOM Object	Use
Domimplementation	A query object that determines the level that the DOM supports
DocumentFragment	Represents a part of a tree (can be cut/pasted)
Document	Represents the top-level node in the tree
NodeList	The iterator object used to access the XML node
Node	Used to extend elements with core XML tags
NamedNodeMap	namespace support and iteration through attribute node collections
Characterdata	Text Manipulation objects
Attr	Represents the attributes of an element
Element	A node representing an XML element that can be used to access a property
Text	Represents the textual content of a given element or Property object
Cdatasection	Used to mask the XML part so that it is not parsed and validated
notation	Contains representations based on DTDs or schemas
Entity	Represents an entity that has been parsed or not parsed
EntityReference	Represents an entity reference node
ProcessingInstruction	Represents a processing instruction

While it is sometimes easier to confuse, XML document objects can be (and often are) polymorphic. That is, "node" is also an "element". This can sometimes be confusing when you are trying to determine what DOM object is needed to perform what action. You can use the Document object to create a DOM node, but if you want to add an attribute to a newly created node, you must access it by using it as a side of the element. If there is a magical pattern of associating objects with operations, then I haven't been able to distill them out of my daily work. I find myself still needing to refer to the MSDN documentation to see which COM interface provides the required method to perform the tasks I am trying to accomplish. The various object methods seem to be logically grouped, which is what I infer from the DOM's original development pattern (by grouping logical operations).

The trick, therefore, is to retrieve the appropriate DOM object from the MSXML parser, which is specifically implemented as a COM object. The basic pattern of the operation would be to instantiate a copy of the MSXML COM object itself first, and then request or otherwise obtain a pointer to an additional XML DOM object (itself also a COM object).

MSXML DOM Test Application

It's easy to create a nice application that demonstrates a number of MSXML features, but in fact, the additional code will only gild the lily. Instead, I chose to develop a simple console-based application that performs four basic operations:

•	Loads an XML file from the disk.
•	Searches for a specific node and inserts a child node into the node.
•	Search for another node and display the (text) value contained within that node.
•	Save the modified XML document back to disk.