DOM模型在MSXML類庫中的主要表現為把XML文件導入內存，形成一個IXMLDOMDocument，再把其中的每一個部件都用一個接口對應起來。因為還沒用MSXML進行過XSLT格式化XML文件，所以這相關的也只好避而不談了。先來個有XML基本部件的文本：
(1)＜?XML version='1.0' encoding='GB2312'?＞
(2)＜?XML-stylesheet type='text/xsl' href='/expert/Xsl/2.xsl'?＞
(3)＜body＞
(4)＜code1 id=”text”＞文本＜/code＞
(5)＜code2 id=”cdata”＞
(6)＜![CDATA[
(7)這裡是CDATA的內容，可以放類似’＜’等可能會和XML控制信息有沖突的內容
(8)]]＞
(9)＜/code＞
(10)＜/body＞
為了表述方便，在第一列都放上了行號。首先從(1)~(10)夠成了一個Document，在MSXML中對應IXMLDOMDocument接口；(1)行、(2)行對應MSXML中的接口為IXMLDOMProcessingInstruction；(3)行到(10)行則為一個Root Element，對應的接口為IXMLDOMElement，(3)裡面包含的多個也是element，不過是body的下一層element。需要注意的是Root只能有一個，Root下面無論多深，理論上允許無數多個(?),且允許名稱重復；(4)和(5)裡面各有一個id=”?”這是一個attribute（注意：(1)和(2)行version;encoding;type;href等也是），對應MSXML裡的IXMLDOMAttribute；(4)裡面的“文本”看起來和(7)這一行是差不多的，都是文本信息，很多人以為都可以通過get_text()直接得到（不久以前我也以為），其實是錯的。對於“文本”是可以通過(4)這個element直接get_text()獲取，對應於IXMLDOMText，但如果在(5)這個element直接get_text()就會出錯，原因？CDATA是區別於“文本”的另外一種類型，對應於IXMLDOMCDATASection，如何獲取，後面再提。現在整個XML的基本框架似乎出來了：
＜IXMLDOMDocument＞
＜IXMLDOMProcessingInstruction /＞
＜IXMLDOMProcessingInstruction /＞
＜IXMLDOMElement (根，只能有一個)＞
＜IXMLDOMElement IXMLDOMAttribute＞
IXMLDOMText
＜/ IXMLDOMElement ＞
＜IXMLDOMElement IXMLDOMAttribute＞
IXMLDOMCDATASection
＜/ IXMLDOMElement ＞
＜IXMLDOMElement＞
＜/IXMLDOMDocument＞
但是，看看很多關於MSXML的教程用到另外一個接口IXMLDOMNode，這個怎麼回事?和上面的IXMLDOMElement有什麼關系?前面用了這麼長時間的MSXML經常就是在這個地方弄混，以至無所進展，最近要在C++Builder5下面使用XML解析，可是沒有TXMLDocument控件，想自己封裝一下MSXML的一些使用才發現其中的奧妙。在DOM模型中把包括Document、ProcessingInstruction、Attribute、Element、TextNode、CDATASection等都看作是一個個Node，在MSXML中實現接口的時候表現為這些對象都是從Node派生出來的，要理解Node和這一些接口的關系關鍵是要看清楚各接口之間的派生關系。為什麼要添加這一個Node接口呢？目的是為了使XML各要素之間聯結起來，不至於松散。
再加上另外兩個接口IXMLDOMNodeList和IXMLDOMNamedNodeMap。其中IXMLDOMNamedNodeMap主要使用在聯結同一個Element的各Attribute，因為同一個Element的Attribute必須保證兩兩不能沖突，而IXMLDOMNodeList則用於聯結其他的幾個要素ProcessingInstruction、Element、TextNode、CDATASection等，而這幾個要素比如Element，在同一個層是允許相同名稱重復出現的。上面的聯結並沒有包括Document這個Node，因為Document是整個XML的第一個Node，不可能也不允許出現在IXMLDOMNodeList和IXMLDOMNamedNodeMap下面。這段說法我也算是經過代碼證實過的吧！把MSXML的Document作為第一個Node，然後通過NamedNodeMap編歷該層的所有Attribute，再通過NodeList遞歸循環下一層的所有Node。可以看到這樣的一個樹狀結構（其中的attribute在該行括號列出，縮進表示所在層）：
#document
XML (version;encoding)
XML-stylesheet (type; href)
body
code1 (id)
#text
code2 (id)
#cdata-section
從上面打印出來的信息可以看出TextNode，CDATASection是當作Element的下一層Node來處理的。get_text()只是為了方便使用TextNode的一個捷徑，對CDATASection通過get_text()訪問會出錯，則可考慮通過下一層Node的第一個Node來獲取。方法：
MSXML::IXMLDOMNodePtr child;
child = parent->childNodes->get_item(0);
if (child != NULL)
text = child->get_nodeValue();
在遞歸循環的時候，通常我們並不能預知這一個Node是什麼類型的。為了知道這一個Node是Element還是TextNode，或者其他類型，可以通過IXMLDOMNode::nodeType來獲取，這是一個枚舉類型，有如下取值（從這也可以看出，上面這個XML文本並沒有涵蓋XML所有要素）：
NODE_ELEMENT (1)
NODE_ATTRIBUTE (2)
NODE_TEXT (3)
NODE_CDATA_SECTION (4)
NODE_ENTITY_REFERENCE (5)
NODE_ENTITY (6)
NODE_PROCESSING_INSTRUCTION (7)
NODE_COMMENT (8)
NODE_DOCUMENT (9)
NODE_DOCUMENT_TYPE (10)
NODE_DOCUMENT_FRAGMENT (11)
NODE_NOTATION (12)
好了，下面應該可以把“XML文件的處理思考”裡面出現的一些問題一個個羅列出來了吧：
問題一：最大的問題，通過路徑來找到比較深入的一個節點
在這篇文章中通過遞歸調用函數來實現這個功能，完全沒有必要，算是多此一舉了。DOM模型中自身帶的IXMLDOMNode::SelectSingleNode和IXMLDOMNode::SelectNodes（XPath）實現了比這個遞歸調用更完美的功能。簡單說一下SelectSingleNode的使用方法(msdom是IXMLDOMDocument實例)
MSXML::IXMLDOMNodePtr parent, child;
parent = msdom->documentElement;
//child為code1類型Element
child = parent->selectSingleNode(“/code1”);
//child為code1的id類型Attribute
child = parent->selectSingleNode(“/code1@id”);
//child名為code1且Attribute id=’text’的那個Element類型Element
child = parent->selectSingleNode(“/code1@[id=’text’]”);
…其它高深點的用法待後研究，為XPath相關。
問題二：C++ Builder6裡面的TXMLDocument並不單純是對MSXML的封裝
為了在C++ Builder 5下面封裝出一個類似的控件來，找了一些相關資料，發現MSXML、OpenXML等DOM模型的解析器都是同一套接口（希望我沒有弄錯），只是內部實現不同。TXMLDocument通過設置Ventor可以設置使用不同的解析器，但是在C++Builder裡面使用方法卻是完全相同的。默認好像是使用MSXML解析，比較優劣，MSXML需在客戶端注冊較新的msxml.dll類庫；SAX的需要附帶較大的dll；OpenXML因為是直接使用一個.pas文件編譯，直接生成到了可執行文件。
問題三：在文章中遍歷NodeList使用了IEnum接口
有點殺雞用牛刀之嫌，現在的遍歷可以這樣：
for (int i = 0; i ＜ nodelist-＞get_length(); i++)
{
child = nodelist-＞get_item((long)i);
name = child-＞get_nodeName();
}
想想原來做的時候應該也用過這個方法，不過當時不知道Node和Element之間的關系，胡亂執行下面這樣的轉換所以轉換出的element == NUL，就以為此路不通。
IXMLDOMElementPtr element = (IXMLDOMNodePtr)node;
問題三：到後來補的一段appendChild的操作，將createElement出來的Element直接轉換成Node再appendChild。其實，這應該是最基礎的一個C++知識，關鍵是要看清MSXML實現的Com裡面也帶有了C++的這種技巧。
現在再來看看C++ Builder 5裡面怎麼解決沒有TXMLDocument控件，要使用MSXML類庫有什麼辦法。
最開始想到的是使用import語句的方法，即
#import "C:Windowssystem32MSXML.DLL" named_guids
可是，import進來能生成tlb和tlh文件，進行編譯卻無法通過，總提示缺少了些什麼，或有一些函數未能導出來（對了，可以在VC++裡面import，然後復制生成的tlb和tlh到C++Builder項目）。於是，直接使用C++ Builder裡面自帶的TVariant類進行COM實例化，調用函數，屬性（OleFunction，OlePropertyGet，OlePropertySet）等。例：
TVariant varMSDOM = CreateOleObject(“MSXML.DOMDocument”);
varMSDOM.OleFunction(L“load”, L”c:tmp.XML”);
TVariant varDoc = varMSDOM.OlePropertyGet(“documentElement”);
直覺是這種調用方法是會比import進來的調用速度要慢。差別好像是import直接通過虛函數表查找函數指針進行調用；OleFunction這些則通過IDispatch接口的invoke函數，間接調用，而且不能調用import進來name_guids的那些函數，如get_nodeName(BSTR *)。不管怎麼樣，通過TVariant還是基本能夠滿足要求，函數的調用。
然後，突然發現C++ Builder的Project上有個Import From Type Library的菜單，也嘗試一下。tlb和tlh文件都生成了，加入工程編譯一下，能夠通過，不過tlh裡面的定義，和調用方法卻和VC裡面的import進來有些不同：
1. VC裡面的實例化直接用智能指針如：
MSXML::IXMLDOMDocumentPtr msdom;
msdom.CreateInstance(__uuidof(MSXML::DOMDocument));
C++Builder裡面的實例化，則通過另外一個編譯器封裝的對象來實現
TCOMIXMLDOMDocument i_XMLdocument = CoDOMDocument::Create();
IXMLDOMDocumentPtr msdom = (IXMLDOMDocumentPtr) i_XMLdocument;
TCOMIXMLDOMDocument的定義在MSXML2_TLB.h裡面可以找到
typedef TComInterfaceTCOMIXMLDOMDocument;
2. C++Builder裡面也有IXMLDOMDocumentPtr msdom，可是這個指針卻不能直接用於判斷是否等於NULL，編譯器會提示錯誤，而應改為：
if ((IXMLDOMDocument *)msdom == NULL)
上面在C++Builder下面使用MSXML的經驗，延伸到其它類型的COM的自動化(automation)，應該是不會有什麼問題的！不是嗎？