.NET Framework应用范围还是比较广泛的。许多开发人员都会使用它来创造出一个适合开发的环境帮助我们提高开发效率。在.NET Framework出现之前，习惯使用MSXML服务——一个基于COM的类库——写Windows的XML的驱动程序。不像.NET Framework中的类，MSXML类库的部分代码比API更深，它完全的嵌在操作系统的底层。#t#
MSXML的确能够与你的应用程序通信，但是它不能真正 的与外部环境结合。 MSXML类库能在win32中被导入，也能在CLR中运用，但它只能作为一个外部服务器组件使用。但是基于.NET Framework的应用程序能直接的进行.NET Framework处理XML的其它命名空间整合使用，并且写出来的代码易于阅读。
作为一个独立的组件，MSXML分析器提供了一些高级的特性如异步分析。这个特性在.NET Framework中的XML类及.NET Framework的其它类都没有提供，但是，.NET Framework中的XML类与其它的类整合可以很轻易的获得相同的功能，在这个基础上你可以增加更多的功能。
.NET Framework处理XML的类提供了基本的分析、查询、转换XML数据的功能。在.NET Framework中，你可以找到支持Xpath查询和XSLT转换的类，及读/写XML文档的类。另外，.NET Framework也包含了其它处理XML的类，例如对象的序列化（XmlSerializer和the SoapFormatter类），应用程序配置（AppSettingsReader类），数据存储（DataSet类）。
既然XML是一种标记语言，就应该有一种工具按一定的语法来分析和理解存储在文档中信息。这个工具就是XML分析器——一个组件用于读标记文本并返回指定平台的对象。
分析器的主要功能就是检查XML文件是否有结构上的错误，剥离XML文件中的标记，读出正确的内容，以交给下一步的应用程序处理。XML是一种用来结构化 文件信息的标记语言，XML规范中对于如何标记文件的结构性有一个详细的法则，解析器就是根据这些法则写出来的软件（多用Java写成）。同HTML一 样，在浏览器中，必须有HTML的分析器，这样浏览器才能够“读懂”各种用HTML标记所组成的网页，将它们显示在我们面前。如果有浏览器的HTML解析 器读不懂的标记，将会返回给我们错误信息。
所有的XML分析器，不管它属于哪个操作平台，不外乎都分以下的两类：基于树或者基于事件的处理器。这两类通常都是用XMLDOM（the Microsoft XML Document Object Model）和SAX（Simple API for XML）来实现。XMLDOM分析器是一个普通的基于树的API——它把XML文档当成一个内存结构树呈现。SAX分析器是基于事件的API——它处理每 个在XML数据流中的元素（它把XML数据放进流中再进行处理）。通常，DOM能被一个SAX流载入并执行，因此，这两类的处理不是相互排斥的。
总的来说，SAX分析器与XMLDOM分析器正好相反，它们的分析模式存在着极大的差别。XMLDOM被很好的定义在它的 functionalition集合里面，你不能扩展它。当它在处理一个大型的文档时，它要占用很大内存空间来处理functionalition这个巨 大的集合。
SAX分析器利用客户端应用程序通过现存的指定平台的对象的实例去处理分析事件。SAX分析器控制整个处理过程，把数据“推出”到处理程序，该处理程序依次接受或拒绝处理数据。这种模式的优点是只需很少的内存空间。
.NET Framework处理XML完全支持XMLDOM模式，但它不支持SAX模式。因为.NET Framework支持两种不同的分析模式：XMLDOM分析器和XML阅读器。它显然不支持SAX分析器，但这并不意味它没有提供类似SAX分析器的功 能。通过XML阅读器SAX的所有的功能都能很容易的实现及更有效的运用。不像SAX分析器，.NET Framework的阅读器整个都运作在客户端应用程序下面。这样，应用程序本身就可以只把真正需要的数据“推出”，然后从XML数据流中跳出来。而 SAX分析模式要处理所有的对应用程序有用和无用的信息。
阅读器是基于.NET Framework流模式工作的，它的工作方式类似于数据库的游标。有趣的是，实现类似游标分析模式的类提供对.NET Framework中的XMLDOM分析器的底层支持。XmlReader、XmlWriter两个抽象类是所有.NET Framework中XML类的基础类，包括XMLDOM类、ADO.NET驱动类及配置类。所以在.NET Framework中你有两种可选的方法去处理XML数据。用XmlReader和XmlWriter类直接处理XML数据，或者用XMLDOM模式处理。
XML阅读器支持一个编程接口，接口用于连接XML文档，“推出”你要的数据。如果你更深入去了解阅读器，你会发现阅读器工作原理类似于我们的桌面 应用程序从数据库中取出数据的原理。数据库服务返回一个游标对象，它包含所有查询结果集，并返回指向目标数据集的开始地址的引用。XML阅读器的客户端收 到一个指向阅读器实例的引用。该实例提取底层的数据流并把取出的数据呈现为一棵XML树。阅读器类提供只读、向前的游标，你可以用阅读器类提供的方法滚动 游标遍历结果集中的每一条数据。 从阅读器中看XML文档不是一个标签文本文件，而是一个序列化的节点集合。它是.NET Framework中的一种特殊的游标模式；在.NET Framework中，你找不到其它的任何一个类似的API函数。
阅读器和XMLDOM分析器有几点不同的地方。XML阅读器是只进的，它没有父、子、祖宗、兄弟节点的概念，而且是只读的。在.NET Framework处理XML中，读写XML文档是分为两种完全不同的功能，分别由XmlReader和XmlWriter类来完成。要编辑XML文档，你可以用 XMLDOM分析器。
.net framework处理xml主要包System.Xml命名空间当中，而xml序列化则在System.Xml.Serialization 命名空间中，***简要说一下有关DTD的概念。
DTD(Document Type Definition，文档类型定义)它是一种规范，可以使商业组织间进行无缝的数据交换，打个比方，如果两个同行业的公司A和B要用XML文件相互交换数据，A公司用〈价格〉标记来表示他们产品的价格信息，而B公司可能用〈售价〉来表示价格信息。如果一 个XML应用程序来读取他们各自的XML文件中的信息时，如果它只知道〈价格〉标记里表示的是价格信息，那么B公司的价格信息就读不出来，必将产生错误。 显然，对于想利用XML文件来交换信息的实体来说，他们之间必须有一个约定——即编写XML文件可以用哪些标记，母元素中能够包括哪些子元素，各个元素出 现的顺序，元素中的属性怎样定义等。这么人帮我们就可以轻松地依据这个DTD 编写一个应用程序，去网上将我们感兴趣的东西自动抓回来。 这就是所谓的DTD，A和B公司在交换数据时都必须遵循一种规范。
现在.NET Framework处理XML的方式中已经有了好几个定义好的DTD，如MathML、SMIL等。MathML（Mathematical Markup Language)即数学置标语言是一种基于XML的标准，用来在互联网上书写数学符号和公式的置标语言。它是由W3C的数学工作组提出的。由于数学符号和公式的结构复杂且符号与符号之间存在多种逻辑关系，MathML的格式十分繁琐。这个东东太复杂了，我懒得去研究它，随它吧。SMIL好像念作smile,是用来操纵多媒体片断（对多媒体片断的有机的、智能的组合）。 看来这东西真的不错！SMIL语言是一套已经规定好的而且非常简单的标记。它用来规定多媒体片断(这里多媒体的包括的范围有：声音文件、视频文件、动画、图片、文字等)在什么时候、在什么地方、以什么样的方式播放。
