XML是原標記語言，在Java中廣泛應用于數據存儲和交換。

1、配置文件

1.1 Windows風格

文件名：config.properties

數據格式：

[Product]
Name=小秘書?

[IM]?
;??所有的文字在實際使用中都會進行相應替換,替換規則如下:
;??$peeruin$?--->?替換為對方的uin??

;??AllInOne在線
Text0=$peernick$開通了小秘書自動應答服務,是否與其[link=open?peeruin=$peeruin$?selfuin=$selfuin$?from=6]小秘書[/link]聊聊?

訪問方式： Product.Name

如： QQ

?

1.2 OO風格

文件名： config.xml

數據格式：

<? xml?version="1.0"?encoding="UTF-8" ?>

< prop >
???? < product >
???????? < name > value </ name >
??? </ product >
</ prop >

訪問方式： product.name

如： Jive

2、XML解析器

2.1 DOM

DOM 是用與平臺和語言無關的方式表示 XML 文檔的官方 W3C 標準。DOM 是以層次結構組織的節點或信息片斷的集合，允許開發人員在樹中尋找特定信息。分析該結構通常需要加載整個文檔和構造層次結構。由于它是基于信息層次的，因而 DOM 被認為是基于樹或基于對象的。

用 DOM 解析模型的優點是編程容易，可以很容易的添加和修改樹中的元素。然而由于使用 DOM 解析器的時候需要處理整個 XML 文檔，所以對性能和內存的要求比較高，尤其是遇到很大的 XML 文件的時候。由于它的遍歷能力，DOM 解析器常用于 XML 文檔需要頻繁的改變的服務中。

2.2 SAX

SAX 解析器采用了基于事件的模型，它在解析 XML 文檔的時候可以觸發一系列的事件，當發現給定的tag的時候，它可以激活一個回調方法，告訴該方法制定的標簽已經找到。只是在讀取數據時檢查數據，不需要將數據存儲在內存中，對內存的要求通常會比較低。但用 SAX 解析器的時候編碼工作會比較困難，而且很難同時訪問同一個文檔中的多處不同數據。

2.3 JDOM

JDOM 自身不包含解析器，它通常使用 SAX2 解析器來解析和驗證輸入 XML 文檔。
JDOM 的目的是成為 Java 特定文檔模型，僅使用具體類而不使用接口，API 大量使用了 Collections 類，簡化了與 XML 的交互，并且比使用 DOM 實現更快。

2.4 DOM4J

DOM4J 合并了許多超出基本 XML 文檔表示的功能，包括集成的 XPath 支持、XML Schema 支持以及用于大文檔或流化文檔的基于事件的處理。它還提供了構建文檔表示的選項，它通過 DOM4J API 和標準 DOM 接口具有并行訪問功能。

DOM4J 是一個非常非常優秀的Java XML API，具有性能優異、功能強大和極端易用使用的特點，同時它也是一個開放源代碼的軟件。

3、DTD vs. XML Schema

XML Schema 指定 XML Schema 定義語言，該語言提供了描述 XML 1.0 文檔結構和限制其內容的工具，其中包括那些利用 XML Namespace 的工具。模式語言自身用 XML 1.0 表示并使用名稱空間，它在很大程度上重構了 XML 1.0 DTD 具有的能力，并在一定程度上擴展了這些能力。

DTD 的局限性:
　　
□ 對于復雜需求通常很難使用內容模型。
□ 不支持名稱空間。
□ 對模塊化和重用的支持非常有限。
□ 不支持對聲明擴展或繼承。
□ 編寫、維護和讀取大型 DTD 以及定義系列相關模式都很困難。
□ 沒有嵌入式、結構化自我文檔編制(self-documentation)(只有 可用)。
□ 內容和屬性聲明不能依靠屬性或元素上下文(許多 XML 語言用到這一點，但它們的 DTD 必須“允許過多東西”)。
□ 只能使用一個簡單的標識屬性機制(換句話說，沒有唯一性作用域)。
　　
XML Schema 的局限性:
　　
□ XML Schema 比較復雜;只需要偶爾使用 XML 的程序員可能覺得它難得有些過頭。
□ XML Schema 不能請求特定的根元素(因此，即使驗證最簡單的文檔也要求額外的信息)。
□ 當描述混合內容時，根本無法約束字符數據。
□ 內容和屬性聲明不能依靠屬性或元素上下文(這也是 DTD 的主要問題)。
□ 不能離開聲明指定缺省值。
□ 元素缺省值只能是字符數據(不包含標記)。