XML，或稱為可擴展標記語言（Extensible Markup Language），是一種您可以用來創建自己的標記的標記語言。它由萬維網協會（W3C）創建，用來克服 HTML（即超文本標記語言（Hypertext Markup Language），它是所有網頁的基礎）的局限。和 HTML 一樣，XML 基于 SGML — 標準通
用標記語言（Standard Generalized Markup Language）。盡管 SGML 已在出版業使用了數十年，但其理解方面的復雜性使許多本打算使用它的人望而卻步（SGML 也代表“聽起來很棒，但或許以后會用（Sounds great, maybe later）”）。XML 是為 Web 設計的。
?
XML文檔規則
有三種 XML 文檔：
無效文檔沒有遵守 XML 規范定義的語法規則。如果開發人員已經在 DTD 或模式中定義了文檔能夠包含什么，而某個文檔沒有遵守那些規則，那
么這個文檔也是無效的。（請參閱定義文檔內容以獲得對 XML 文檔 的 DTD 和模式的專門介紹。）
有效文檔既遵守 XML 語法規則也遵守在其 DTD 或模式中定義的規則。
格式良好的文檔遵守 XML 語法，但沒有 DTD 或模式。
根元素
XML 文檔必須包含在一個單一元素中。這個單一元素稱為根元素，它包含文檔中所有文本和所有其它元素。在下面的示例中，XML 文檔包含在一
個單一元素 <greeting> 中。請注意文檔有一行注釋在根元素之外；那是完全合乎規則的。
<?xml version="1.0"?>
<!-- A well-formed document -->
<greeting>
? Hello, World!
</greeting>
?????????
下面是一個不包含單一根元素的文檔：
<?xml version="1.0"?>
<!-- An invalid document -->
<greeting>
? Hello, World!
</greeting>
<greeting>
? Hola, el Mundo!
</greeting>
?????????
不管該文檔可能包含什么信息，XML 解析器都會拒絕它。
元素不能重疊
XML 元素不能重疊。下面是一些不合乎規則的標記：
<!-- NOT legal XML markup -->???????????
<p>
? <b>I <i>really
? love</b> XML.
? </i>
</p>
?????????
如果您在 <b> 元素中開始了 <i> 元素，則必須在 <b> 元素中結束 <i> 元素。如果您希望文本 XML 以斜體出現，那么您需要添加第二個 <i>
元素以更正標記：
<!-- legal XML markup -->
<p>
? <b>I <i>really
? love</i></b>
? <i>XML.</i>
</p>
?????????
XML 解析器將只接受這種標記；大多數 Web 瀏覽器中的 HTML 解析器對于兩者都接受。
結束標記是必需的
不能省去任何結束標記。在下面第一個示例中，標記是不合乎規則的，因為沒有結束段落（</p>）標記。盡管這在 HTML（以及某些情況下在
SGML）中可以接受，但 XML 解析器將拒絕它。
<!-- NOT legal XML markup -->
<p>Yada yada yada...
<p>Yada yada yada...
<p>...
?????????
如果一個元素根本不包含標記，則稱為空元素；HTML 換行（<br>）和圖像（<img>）元素就是兩個例子。在 XML 文檔的空元素中，您可以把結束
斜杠放在開始標記中。下面的兩個換行元素和兩個圖像元素對于 XML 解析器來說是一回事：
<!-- Two equivalent break elements -->
<br></br>
<br />
<!-- Two equivalent image elements -->
<img src="../img/c.gif"></img>
<img src="../img/c.gif" />
元素是區分大小寫的
XML 元素是區分大小寫的。在 HTML 中，<h1> 和 <H1> 是相同的；在 XML 中，它們是不同的。如果您試圖用 </H1> 標記結束 <h1> 元素，將會
出錯。在下面的示例中，頂部的標題是不合乎規則的，而底部的則是正確的。
<!-- NOT legal XML markup -->
<h1>Elements are
? case sensitive</H1>
<!-- legal XML markup -->
<h1>Elements are
? case sensitive</h1>
屬性必須有用引號括起的值
XML 文檔中的屬性有兩個規則：
屬性必須有值
那些值必須用引號括起。
?
比較下面的兩個示例。頂部的標記在 HTML 中是合乎規則的，但在 XML 中則不是。為了在 XML 中取得相同結果，您必須給屬性賦值，而且必須
把值括在引號中。
<!-- NOT legal XML markup -->
<ol compact>
<!-- legal XML markup -->
<ol compact="yes">
?????????
您可以使用單引號，也可以使用雙引號，但要始終保持一致。
如果屬性值包含單引號或雙引號，則您可以使用另一種引號來括起該值（如 name="Doug's car"），或使用實體 " 代表雙引號，使用
' 代表單引號。實體是一個符號（如 "），XML 解析器會用其它文本代替該符號（如 "）。
?
XML 聲明
大多數 XML 文檔以 XML 聲明作為開始，它向解析器提供了關于文檔的基本信息。建議使用 XML 聲明，但它不是必需的。如果有的話，那么它一
定是文檔的第一樣東西。
聲明最多可以包含三個名稱-值對（許多人稱它們為屬性，盡管在技術上它們并不是）。version 是使用的 XML 版本；目前該值必須是 1.0。
encoding 是該文檔所使用的字符集。該聲明中引用的 ISO-8859-1 字符集包括大多數西歐語言用到的所有字符。如沒有指定 encoding，XML 解
析器會假定字符在 UTF-8 字符集中，這是一個幾乎支持世界上所有語言的字符和象形文字的 Unicode 標準。
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
?????????
最后，standalone（可以是 yes 或 no）定義了是否可以在不讀取任何其它文件的情況下處理該文檔。例如，如果 XML 文檔沒有引用任何其它文
件，則您可以指定 standalone="yes"。如果 XML 文檔引用其它描述該文檔可以包含什么的文件（馬上會詳細介紹這些文件），則您可以指定
standalone="no"。因為 standalone="no" 是缺省的，所以您很少會在 XML 聲明中看到 standalone。
XML 文檔中的其它項
您或許會在一個 XML 文檔中發現其它幾項：
注釋：注釋可以出現在文檔的任何位置；它們甚至可以出現在根元素的前面或后面。注釋以 <!-- 開始，以 --> 結束。注釋不能在結束部分以外
包含雙連字符（--）；除此之外，注釋可以包含任何內容。最重要的是，注釋內的任何標記都被忽略；如果您希望除去 XML 文檔的一塊較大部分
，只需用注釋括住那個部分即可。（要恢復這個注釋掉的部分，只需除去注釋標記即可。）下面是包含注釋的標記：
<!-- Here's a PI for Cocoon: -->
<?cocoon-process type="sql"?>
?????????
處理指令：處理指令是為使用一段特殊代碼而設計的標記。在上面的示例中，有一個用于 Cocoon 的處理指令（有時稱為 PI），Cocoon 是來自
Apache 軟件基金會（Apache Software Foundation）的 XML 處理框架。當 Cocoon 處理 XML 文檔時，它會尋找以 cocoon-process 開頭的處理
指令，然后相應地處理 XML 文檔。在該示例中，type="sql" 屬性告訴 Cocoon：XML 文檔包含一個 SQL 語句。
<!-- Here's an entity: -->
<!ENTITY dw "developerWorks">
?????????
實體：上面的示例為文檔定義了一個實體。無論 XML 處理器在何處找到字符串 &dw;，它都會用字符串 developerWorks 代替該實體。XML 規范
還定義了五個您可以用來替代不同的特殊字符的實體。這些實體是：
< 代表小于符號
> 代表大于符號
" 代表一個雙引號
' 代表一個單引號（或撇號）
& 代表一個“與”符號。
名稱空間
XML 的能力來自它的靈活性，即您和我以及數百萬其他人可以定義我們自己的標記來描述我們的數據。記得表示個人姓名和地址的樣本 XML 文檔
嗎？那個文檔包括表示個人尊稱的 <title> 元素，這是對元素名稱非常合理的選擇。如果您經營一家網上書店，您或許會創建一個表示書名的
<title> 元素。如果您經營一家網上抵押放款公司，您或許會創建表示一份財產名稱的 <title> 元素。所有這些都是合理的選擇，但它們都用相
同的名稱創建元素。如何分辨某個特定的 <title> 元素指的是人、書籍還是一份財產呢？可以使用名稱空間。
要使用名稱空間，您要定義一個名稱空間前綴，然后將它映射至一個特殊字符串。下面介紹如何定義我們這三個 <title> 元素的名稱空間前綴：
在該示例中，三個名稱空間前綴是 addr、books 和 mortgage。請注意，為特定元素定義名稱空間意味著該元素的所有子元素都屬于同一名稱空
間。第一個 <title> 元素屬于 addr 名稱空間，因為其父元素 <addr:Name> 屬于該名稱空間。
最后要指出的是：名稱空間定義中的字符串僅僅是字符串。對，這些字符串看似 URL，其實不是。您可以定義 xmlns:addr="mike"，那也是有效
的。名稱空間唯一的重要性在于其唯一性；這就是為什么大多數名稱空間定義看起來象 URL 的原因。XML 解析器不會到
?
定義文檔內容???
在了解到了 XML 文檔的基本規則之后，您需要定義將用來表示數據的元素。做到這一點的兩種方法。
一種方法是使用文檔類型定義（Document Type Definition），或簡稱 DTD。DTD 定義可以在 XML 文檔中出現的元素、這些元素出現的次序、它
們可以如何相互嵌套以及 XML 文檔結構的其它詳細信息。DTD 是最初的 XML 規范的一部分，與 SGML DTD 非常相似。
另一種方法是使用 XML Schema。模式可以定義您能在 DTD 中使用的所有文檔結構，它還可以定義數據類型和比 DTD 更復雜的規則。W3C 在提出
最初的 XML 規范的幾年之后開發了 XML Schema 規范。?
?
文檔類型定義
DTD 允許您指定 XML 文檔的基本結構。下面的幾頁將研究 DTD 片段。首先是定義本章中地址文檔示例的基本結構的 DTD，XML 是什么？：
<!-- address.dtd -->
<!ELEMENT address (name, street, city, state, postal-code)>
<!ELEMENT name (title? first-name, last-name)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT first-name (#PCDATA)>
<!ELEMENT last-name (#PCDATA)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT postal-code (#PCDATA)>
?????????
該 DTD 定義了樣本文檔中使用的所有元素。它定義了三個元素：
<address> 元素包含一個 <name>、一個 <street>、一個 <city>、一個 <state> 和一個 <postal-code>。所有這些元素必須出現，而且必須以
這個順序出現。
<name> 元素包含一個可選的 <title> 元素（問號表示 title 這個元素是可選的），后面跟有一個 <first-name> 和一個 <last-name> 元素。
所有其它包含文本的元素。（#PCDATA 代表已解析字符數據；不能在這些元素中包含另一個元素。）
盡管 DTD 相當簡單，但它清楚地說明了什么樣的元素組合是合乎規則的。<postal-code> 元素在 <state> 元素之前的地址文檔是不合乎規則的
，沒有 <last-name> 元素的文檔也不合乎規則。
另外，請注意，DTD 語法不同于普通的 XML 語法。（相反，XML Schema 文檔本身就是 XML，這導致一些有趣的結果）。盡管 DTD 的語法不同，
但您仍可以將普通的注釋放到 DTD 中。
DTD 中的符號
DTD 中有幾個符號用于指出某元素在 XML 文檔中可能會出現多少次（或是否出現）。下面是一些示例及其含義：
<!ELEMENT address (name, city, state)>
<address> 元素必須包含一個 <name> 元素、一個 <city> 元素和一個 <state> 元素，并且符合上面的次序。所有的元素都是必需的。逗號表示
項的列表。
<!ELEMENT name (title?, first-name, last-name)>
這意味著 <name> 元素包含一個可選的 <title> 元素，后面必須跟有一個 <first-name> 和一個 <last-name> 元素。問號表示這一項是可選的
；它可以出現一次或根本不出現。
<!ELEMENT addressbook (address+)>
<addressbook> 元素包含一個或多個 <address> 元素。您可以有任意多的 <address> 元素，但必須至少有一個。加號表示這一項必須至少出現
一次，但可出現任意次。
<!ELEMENT private-addresses (address*)>
<private-addresses> 元素包含零個或多個 <address> 元素。星號表示這一項可以出現任意次，包括零次。
<!ELEMENT name (title?, first-name, (middle-initial | middle-name)?, last-name)>
<name> 元素包含一個可選的 <title> 元素，后面跟有一個 <first-name> 元素，隨后可能跟有一個 <middle-initial> 或 <middle-name> 元素
，然后跟有一個 <last-name> 元素。換句話說，<middle-initial> 和 <middle-name> 都是可選的，而且您只能選擇二者中的一個。豎線符號表
示選擇列表；您只能從列表選擇一項。還要注意該示例用圓括號對特定元素進行分組，然后在這個組旁放上問號。
<!ELEMENT name ((title?, first-name, last-name) | (surname, mothers-name, given-name))>
這個 <name> 元素可以包含兩個序列中的一個：一個可選的 <title>，后面跟有一個 <first-name> 和一個 <last-name>；或一個 <surname>、
一個 <mothers-name> 和一個 <given-name>。
?
定義屬性
本篇介紹性教程沒有很詳細地研究 DTD 如何工作，但這里要介紹一個更基本的概念：定義屬性。您可以定義將在 XML 文檔中出現的元素的屬性
。使用 DTD，您還可以：
定義哪些屬性是必需的
定義屬性的缺省值
列出給定屬性的所有有效值
假設您要更改 DTD，使 state 成為 <city> 元素的屬性。下面演示如何做到這一點：
<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA #REQUIRED>
?????????
和以前一樣，我們定義了 <city> 元素，但修改的示例還使用了 ATTLIST 聲明來列出元素的屬性。屬性列表中的名稱 city 告訴解析器這些屬性
是為 <city> 元素定義的。名稱 state 是屬性的名稱，關鍵字 CDATA 和 #REQUIRED 告訴解析器 state 屬性包含文本并且是必需的（如果它是
可選的，用 CDATA #IMPLIED 即可）。
要定義元素的多個屬性，可象下面那樣編寫 ATTLIST：
<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA #REQUIRED
?????????????? postal-code CDATA #REQUIRED>
?????????
該示例將 state 和 postal-code 都定義為 <city> 元素的屬性。
最后，DTD 允許您定義屬性缺省值，并列舉屬性的所有有效值：
<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA (AZ|CA|NV|OR|UT|WA) "CA">
?????????
上面的示例表明它僅支持來自亞利桑那州（AZ）、加利福尼亞州（CA）、內華達州（NV）、俄勒岡州（OR）、猶他州（UT）和華盛頓州（WA）的地址，并且缺省值是加利福尼亞州。這樣，您就可以進行形式非常有限的數據驗證。盡管這是有用的功能，但它只是您能用 XML 模式（請參閱
XML 模式）完成的工作的一個小子集。
?
XML 模式
使用 XML 模式，您會有更多的能力來定義什么樣的 XML 文檔是有效的。它們與 DTD 相比有幾個優勢：
XML 模式使用 XML 語法。換句話說，XML 模式是一個 XML 文檔。這意味著您可以象處理任何其它文檔一樣處理模式。例如，您可以編寫一個 XSLT 樣式表，該樣式表將 XML 模式轉換成具有自動生成的 JavaScript 代碼的 Web 表單，其中的 JavaScript 代碼可以驗證您輸入的數據。
XML 模式支持數據類型。盡管 DTD 確實支持數據類型，但很明顯這些數據類型是從發布的角度開發的。XML 模式支持 DTD 中的所有原始數據類型（諸如標識和標識引用之類的類型）。它們還支持整數、浮點數、日期、時間、字符串、URL 和其它對數據處理和驗證有用的數據類型。
XML 模式是可擴展的。除了 XML 模式規范中定義的數據類型以外，您還可以創建自己的數據類型，并且可以基于其它數據類型派生出新的數據類型。
XML 模式有更強的表達能力。例如，您可以用 XML 模式定義任何 <state> 屬性值不得超過 2 個字符，或定義任何 <postal-code> 元素的值必
須與正則表達式 [0-9]{5}(-[0-9]{4})? 相匹配。您無法用 DTD 做這些事。
?
樣本 XML 模式
下面是與原始名稱和地址 DTD 相匹配的 XML 模式。它增加了兩個約束：<state> 元素的值必須剛好是兩個字符長，<postal-code> 元素的值必
須與正則表達式 [0-9]{5}(-[0-9]{4})? 相匹配。盡管這個模式比 DTD 長很多，但它更清楚地表達了有效的文檔看起來是什么樣子。下面是模式
：
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="
http://www.w3.org/2001/XMLSchema">
? <xsd:element name="address">
??? <xsd:complexType>
????? <xsd:sequence>
??????? <xsd:element ref="name"/>
??????? <xsd:element ref="street"/>
??????? <xsd:element ref="city"/>
??????? <xsd:element ref="state"/>
??????? <xsd:element ref="postal-code"/>
????? </xsd:sequence>
??? </xsd:complexType>
? </xsd:element>
? <xsd:element name="name">
??? <xsd:complexType>
????? <xsd:sequence>
??????? <xsd:element ref="title" minOccurs="0"/>
??????? <xsd:element ref="first-Name"/>
??????? <xsd:element ref="last-Name"/>
????? </xsd:sequence>
??? </xsd:complexType>
? </xsd:element>
? <xsd:element name="title"????? type="xsd:string"/>
? <xsd:element name="first-Name" type="xsd:string"/>
? <xsd:element name="last-Name"? type="xsd:string"/>
? <xsd:element name="street"???? type="xsd:string"/>
? <xsd:element name="city"?????? type="xsd:string"/>
? <xsd:element name="state">
??? <xsd:simpleType>
????? <xsd:restriction base="xsd:string">
??????? <xsd:length value="2"/>
????? </xsd:restriction>
??? </xsd:simpleType>
? </xsd:element>
? <xsd:element name="postal-code">
??? <xsd:simpleType>
????? <xsd:restriction base="xsd:string">
??????? <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
????? </xsd:restriction>
??? </xsd:simpleType>
? </xsd:element>
</xsd:schema>
?????????
定義模式中的元素樣本 XML 模式中的 XML 模式用 <xsd:element> 元素定義了一些 XML 元素。頭兩個定義的元素（<address> 和 <name>）由其它元素組成。
<xsd:sequence> 元素定義了包含在這兩個元素中的元素的序列。下面是示例：
<xsd:element name="address">
? <xsd:complexType>
??? <xsd:sequence>
????? <xsd:element ref="name"/>
????? <xsd:element ref="street"/>
????? <xsd:element ref="city"/>
????? <xsd:element ref="state"/>
????? <xsd:element ref="postal-code"/>
??? </xsd:sequence>
? </xsd:complexType>
</xsd:element>
?????????
與 DTD 版本一樣，XML 模式示例定義 <address> 包含一個 <name>、一個 <street>、一個 <city>、一個 <state> 和一個 <postal-code> 元素
，并且依照上面的次序。請注意，該模式實際上用 <xsd:complexType> 元素定義了新的數據類型。
大多數元素包含文本；定義它們很簡單。您只要聲明新的元素，然后指定它的數據類型為 xsd:string：
<xsd:element name="title"????? type="xsd:string"/>
<xsd:element name="first-Name" type="xsd:string"/>
<xsd:element name="last-Name"? type="xsd:string"/>
<xsd:element name="street"???? type="xsd:string"/>
<xsd:element name="city"?????? type="xsd:string"/>
?????????
定義模式中的元素內容
樣本模式為兩個元素的內容定義了約束：<state> 元素的內容必須是兩個字符長，而 <postal-code> 元素的內容必須與正則表達式 [0-9]{5}(-
[0-9]{4})? 匹配。下面演示如何做到那一點：
? <xsd:element name="state">
??? <xsd:simpleType>
????? <xsd:restriction base="xsd:string">
??????? <xsd:length value="2"/>
????? </xsd:restriction>
??? </xsd:simpleType>
? </xsd:element>
? <xsd:element name="postal-code">
??? <xsd:simpleType>
????? <xsd:restriction base="xsd:string">
??????? <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
????? </xsd:restriction>
??? </xsd:simpleType>
? </xsd:element>
?????????
對于 <state> 和 <postal-code> 元素，模式用約束定義了新的數據類型。第一個情況使用 <xsd:length> 元素，而第二個情況則使用
<xsd:pattern> 元素定義該元素必須匹配的正則表達式。
這里概要的介紹僅僅觸及 XML 模式能力的表面；有整本的書籍討論這個主題。就這篇介紹性文章而言，我們足以說明 XML 模式是描述什么樣的
XML 文檔才算有效的非常強大和靈活的方式。
?
?
?XML 編程接口
本章將研究 XML 的多種編程接口。這些接口為開發人員使用 XML 文檔提供了一致的接口。有許多 API 可以使用；本章研究最流行和廣泛使用的
API 中的四種：文檔對象模型（Document Object Model (DOM)）、用于 XML 的簡單 API（Simple API for XML (SAX)）、JDOM 和用于 XML 解
析的 Java API（Java API for XML Parsing (JAXP)）。（您可以通過參考資料中的大量鏈接找到有關這些 API 的更多信息。）
文檔對象模型
文檔對象模型（通常稱為 DOM）為 XML 文檔的已解析版本定義了一組接口。解析器讀入整個文檔，然后構建一個駐留內存的樹結構，然后您的代
碼就可以使用 DOM 接口來操作這個樹結構。您可以遍歷樹以了解原始文檔包含了什么，您可以刪除樹的幾個部分，還可以重新排列樹和添加新的
分支，等等。
DOM 由 W3C 創建，并且是該協會的正式建議書。
DOM 問題
DOM 提供了一組豐富的功能，您可以用這些功能來解釋和操作 XML 文檔，但使用它們是有代價的。在開發用于 XML 文檔的原始 DOM 時，XML-
DEV 郵件列表上的許多人提出了 DOM 的幾個問題：
DOM 構建整個文檔駐留內存的樹。如果文檔很大，就會要求有極大的內存。
DOM 創建表示原始文檔中每個東西的對象，包括元素、文本、屬性和空格。如果您只需關注原始文檔的一小部分，那么創建那些永遠不被使用的
對象是極其浪費的。
DOM 解析器必須在您的代碼取得控制權之前讀取整個文檔。對于非常大的文檔，這會引起顯著的延遲。
這些僅僅是由文檔對象模型的設計引起的問題；撇開這些問題，DOM API 是解析 XML 文檔非常有用的方法。
用于 XML 的簡單 API? 第 4 頁（共8 頁）
?
為了解決 DOM 問題，XML-DEV 參與者們（由 David Megginson 領導）創建了 SAX 接口。SAX 的幾個特征解決了 DOM 的問題：
SAX 解析器向您的代碼發送事件。當解析器發現元素開始、元素結束、文本、文檔的開始或結束等時，它會告訴您。您可以決定什么事件對您重
要，而且可以決定要創建什么類型的數據結構以保存來自這些事件的數據。如果您沒有顯式地保存來自某個事件的數據，它就被丟棄。
SAX 解析器根本不創建任何對象，它只是將事件傳遞給您的應用程序。如果希望基于那些事件創建對象，這將由您來完成。
SAX 解析器在解析開始的時候就開始發送事件。當解析器發現文檔開始、元素開始和文本等時，代碼會收到一個事件。您的應用程序可以立即開
始生成結果；您不必一直等到整個文檔被解析完畢。更妙的是，如果您只查找文檔中某些內容，代碼一旦找到所要找的東西就可以拋出一個異常
。該異常會停止 SAX 解析器，然后代碼用它找到的數據做它需要做的任何事。
該說的都已經說了，SAX 和 DOM 各有千秋。本章余下的部分將討論為什么您可能需要使用不同的接口。
?
SAX 問題
公平而言，SAX 解析器也有些問題引人關注：
SAX 事件是無狀態的。當 SAX 解析器在 XML 文檔中發現文本時，它就向您的代碼發送一個事件。該事件僅僅給您發現的文本；它不告訴您什么
元素包含那個文本。如果您想知道這一點，則必須自己編寫狀態管理代碼。
SAX 事件不是持久的。如果應用程序需要一個數據結構來對 XML 文檔建模，則必須自己編寫那樣的代碼。如果您需要從 SAX 事件訪問數據，并
且沒有把那個數據存儲在代碼中，那么您不得不再次解析該文檔。
SAX 不是由一個集中管理的組織控制的。盡管到目前為止這還沒有引起什么問題，但如果 SAX 是由象 W3C 這樣的一個組織控制的話，有些開發
人員會感覺更自在。
?
JDOM
用 DOM 和 SAX 模型完成某些任務時的困難使 Jason Hunter 和 Brett McLaughlin 感到失望，于是他們創建了 JDOM 包。JDOM 是基于 Java 技
術的開放源碼項目，它試圖遵循 80/20 規則：用 DOM 和 SAX 20% 的功能來滿足 80% 的用戶需求。JDOM 使用 SAX 和 DOM 解析器，因此它是作
為一組相對較小的 Java 類被實現的。
JDOM 的主要特性是它極大地減少了您必須編寫的代碼數量。盡管本篇介紹性教程并不深入討論編程主題，但 JDOM 應用程序的長度通常是 DOM
應用程序的三分之一，大約是 SAX 應用程序的一半。（當然，堅持使用 DOM 的純粹主義者會建議說：從長遠來看，學習和使用 DOM 終會有所回
報）。JDOM 并不做所有的事，但對于大多數您要做的解析，它可能正好適合您。
用于 XML 解析的 Java API
盡管 DOM、SAX 和 JDOM 為大多數常見任務提供了標準接口，但仍有些事情是它們不能解決的。例如，在 Java 程序中創建 DOMParser 對象的過
程因 DOM 解析器的不同而不同。為了修正這個問題，Sun 發布了 JAXP（用于 XML 解析的 Java API，Java API for XML Parsing）。該 API 為
使用 DOM、SAX 和 XSLT 處理 XML 文檔提供了公共接口。
JAXP 提供的諸如 DocumentBuilderFactory 和 DocumentBuilder 之類的接口為不同的解析器提供了一個標準接口。還有一些方法可以允許您控
制底層的解析器是否可以識別名稱空間以及是否使用 DTD 或模式來驗證 XML 文檔。
哪種接口適合您？
為了確定哪種接口適合您，您需要理解所有接口的設計要點，而且需要理解應用程序用您將要處理的 XML 文檔來做什么。考慮下面的問題將有助
于您找到正確的方法。
要用 Java 編寫應用程序嗎？JAXP 使用 DOM、SAX 和 JDOM；如果您用 Java 編寫代碼，那么您應使用 JAXP 將您的代碼與各種解析器實現的細
節隔離。
應用程序將如何部署？如果您的應用程序將要作為 Java applet 部署，那么您會希望使要下載的代碼數量最小，別忘了 SAX 解析器比 DOM 解析
器小。還要知道使用 JDOM 時，除了 SAX 或 DOM 解析器之外還要求編寫少量的代碼。
一旦解析了 XML 文檔，還需要多次訪問那些數據嗎？如果您需要回過頭來訪問 XML 文件的已解析版本，DOM 可能是正確的選擇。而 SAX 事件被
觸發時，如果您以后需要它，則由您（開發人員）自己決定以某種方式保存它。如果您需要訪問不曾保存的事件，則必須再次解析該文件。而
DOM 自動保存所有的數據。
只需要 XML 源文件的少量內容嗎？如果您只需要 XML 源文件的少量內容，那么 SAX 可能是正確的選擇。SAX 不會為源文件中的每個東西創建對
象；您要確定什么是重要的。使用 SAX，您要檢查每個事件以了解它是否與您的需要有關，然后相應地處理它。更妙的是，一旦找到您正在尋找
的東西，您的代碼就會拋出一個異常來完全停止 SAX 解析器。
您正在一臺內存很少的機器上工作嗎？若是的話，不管您可能考慮到的其它因素是什么，SAX 是您的最佳選擇。
要知道還存在用于其它語言的 XML API；尤其是 Perl 和 Python 社區有極佳的 XML 工具。
?
?
XML 標準
XML 世界中存在多種標準。除了基本 XML 標準以外，其它標準定義了模式、樣式表、鏈接、Web 服務、安全性和其它重要項目。本章介紹最流行
的 XML 標準，并為您指出了查找其它標準的參考資料。
names/。
XML Schema
XML Schema 語言定義成以下三個部分：
入門位于 w3.org/TR/xmlschema-0，它介紹了 XML 模式文檔及其設計用途；
文檔結構的標準位于w3.org/TR/xmlschema-1，它說明了如何定義 XML 文檔的結構；
數據類型的標準位于w3.org/TR/xmlschema-2，它定義了一些常用數據類型以及創建新類型的規則。
本教程在定義文檔內容中簡要地介紹了模式；如果您對于用 XML 模式可以做的所有事情，需要了解完整的詳細信息，那么最好先閱讀“入門”。
?
XSL、XSLT 和 XPath
可擴展樣式表語言（Extensible Stylesheet Language（XSL））定義了一組元素（稱為格式化對象），它們描述應該如何格式化數據。為清晰起
見，通常將該標準稱為 XSL-FO 以和 XSLT 進行區分。盡管它主要是設計用于生成高質量的可打印文檔，但您也可以使用格式化對象從 XML 生成
音頻文件。XSL-FO 標準位于 w3.org/TR/xsl/。
用于轉換的可擴展樣式表語言（Extensible Stylesheet Language for Transformation（XSLT））是一個描述如何將 XML 文檔轉換成別的東西
的 XML 詞匯表。該標準位于w3.org/TR/xslt（結尾沒有斜杠符號）。
XPath（XML 路徑語言，XML Path Language）是描述 XML 文檔中位置的語法。您使用 XSLT 樣式表中的 XPath 來描述您希望轉換 XML 文檔的哪
個部分。XPath 也用在其它 XML 標準中，這就是為什么它是獨立于 XSLT 的標準的原因。XPath 在 w3.org/TR/xpath（結尾沒有斜杠符號）中定
義。
DOM
文檔對象模型定義了如何將 XML 文檔轉換為駐留內存的樹結構。DOM 在 W3C 的許多規范中都有定義：
核心 DOM 定義 DOM 本身、樹結構、以及代碼遍歷樹時會發現的各種節點和異常。完整的規范在 w3.org/TR/DOM-Level-2-Core/。
事件定義對于樹可以發生的事件，以及如何處理這些事件。該規范試圖協調 Netscape 和 Internet Explorer 瀏覽器的版本 4 之后所支持對象
模型之間的差異。該規范位于 w3.org/TR/DOM-Level-2-Events/。
樣式定義程序如何訪問 XSLT 樣式表和 CSS 樣式表。該規范位于 w3.org/TR/DOM-Level-2-Style/。
遍歷和范圍定義一些允許程序遍歷樹或定義樹中節點范圍的接口。可以在 w3.org/TR/DOM-Level-2-Traversal-Range/ 找到完整的規范。
視圖為文檔本身定義 AbstractView 接口。請參閱 w3.org/TR/DOM-Level-2-Views/ 以獲得更多信息。
?
SAX、JDOM 和 JAXP
用于 XML 的簡單 API 定義了一些事件和接口，用于與符合 SAX 的 XML 解析器進行交互。可以在
www.saxproject.org 上找到完整的 SAX 規范
。
Jason Hunter 和 Brett McLaughlin 創建的 JDOM 項目位于 jdom.org/。在 JDOM 站點，您可以找到代碼、樣本程序和其它能幫助您入門的工具
。（有關在 developerWorks 上介紹 JDOM 的文章，請參閱參考資料）。
有關 SAX 和 JDOM 的重要一點是：二者都來自 XML 開發人員社區，而不是標準組織。它們獲得的廣泛接受是對全世界 XML 開發人員積極參與的
回報。
您可以在 java.sun.com/xml/jaxp/ 找到所有與 JAXP 有關的內容。
鏈接和引用
在 XML 世界中有兩個用于鏈接和引用的標準：XLink 和 XPointer：
XLink（XML 鏈接語言，XML Linking Language）定義將不同資源鏈接在一起的各種方法。您可以進行正常的點對點鏈接（就象用 HTML <a> 元素
）或擴展的鏈接，后者可包括多點鏈接、通過第三方的鏈接以及定義轉向給定鏈接的意義的規則。XLink 標準位于
www.w3.org/TR/xlink/。
XPointer（XML 指針語言，XML Pointer Language）使用 XPath 作為引用其它資源的方法。它還包括對 XPath 的一些擴展。可以在
安全性
有兩個處理 XML 文檔安全性的重要標準。一個是 XML 數字簽名（XML Digital Signature）標準（w3.org/TR/xmldsig-core/），它定義了用于
數字簽名的 XML 文檔結構。您可以為任何類型的數據創建 XML 數字簽名，不管它是 XML 文檔、HTML 文件、純文本、二進制數據還是其它東西
。您可以用數字簽名來驗證一個特定文件自簽名后沒有被修改過。如果您要簽名的數據是 XML 文檔，您可以將 XML 文檔嵌入簽名文件本身，這
會使數據和簽名的處理變得非常簡單。
另一個標準用于加密 XML 文檔。可以將 XML 文檔編寫得易于人們閱讀和理解，盡管這樣做很好，但如果文檔落入壞人之手就會引起麻煩。XML
加密（XML Encryption）標準（w3.org/TR/xmlenc-core/）定義了如何加密 XML 文檔的各部分。
將這些標準一起使用，您就能放心地使用 XML 文檔了。我可以對一個重要的 XML 文檔進行數字簽名，生成一個包含 XML 文檔本身的簽名。然后
我可以加密該文檔（使用我的私鑰和您的公鑰）然后把它發送給您。當您收到文檔時，您可以用您的私鑰和我的公鑰解密該文檔；這可以讓您知
道是我發送的文檔。（如果需要，您還可以證明我發送了文檔）。一旦您解密了文檔，您可以使用該數字簽名確定文檔沒有經過任何修改。
?
Web 服務
Web 服務是一種新的重要的應用程序。Web 服務是一段可以用 XML 發現、描述和訪問的代碼。在這一領域有許多活動，但有三種主要的用于 Web
服務的 XML 標準：
SOAP：最初是簡單對象訪問協議（Simple Object Access Protocol），SOAP 定義一個 XML 文檔格式，該格式描述如何調用一段遠程代碼的方法
。我的應用程序創建一個描述我希望調用的方法的 XML 文檔，并傳遞給它所有必需的參數，然后應用程序通過網絡將該 XML 文檔發送給那段代
碼。代碼接收 XML 文檔、解釋它、調用我請求的方法，然后發回一個描述結果的 XML 文檔。SOAP 規范版本 1.1 位于 w3.org/TR/SOAP/。請訪
問 w3.org/TR/ 以了解 W3C 中 SOAP 相關的所有活動。
WSDL：Web 服務描述語言（Web Services Description Language）是一個描述 Web 服務的 XML 詞匯表。編寫一段接收 WSDL 文檔然后調用其以
前從未用過的 Web 服務的代碼，這是可能的。WSDL 文件中的信息定義 Web 服務的名稱、它的方法的名稱、這些方法的參數和其它詳細信息。您
可以在 w3.org/TR/wsdl（結尾沒有斜杠符號）找到最新的 WSDL 規范。
UDDI：統一描述、發現和集成（Universal Description, Discovery, and Integration）協議向 Web 服務注冊中心定義 SOAP 接口。如果您有
一段代碼希望作為 Web 服務部署，UDDI 規范定義如何將您的服務描述添加至注冊中心。如果您在尋找一段提供某種功能的代碼，UDDI 規范定義
其它標準
還有許多其它的 XML 標準，我沒有在這里深入介紹。除了象可伸縮向量圖（Scalable Vector Graphic）（
www.w3.org/TR/SVG/）、SMIL（同步
最后，要查找有關 XML 標準的優秀信息來源，請訪問 xml.org/xml/registry.jsp 上的 XML 資源庫。該站點的特點是有數百個用于各行各業的
標準。
現實世界示例
到目前為止，我希望您相信 XML 具有能使電子商務的運行方式發生革命性變化的極大潛力。盡管潛力是巨大的，但真正重要的是市場中的實際結
果。本章描述了三個案例研究，案例中的組織使用了 XML 來簡化其業務過程并改進其結果。
這里討論的所有案例研究都來自 IBM 的 jStart 計劃。jStart 團隊的任務是幫助客戶使用新技術來解決問題。當客戶同意 jStart 約定時，他
會以一定的折扣得到 IBM 咨詢和開發服務，客戶將被明確告之由此產生的項目將會被作為案例研究使用。如果您想看到更多案例研究，包括涉及
Web 服務和其它新技術的案例研究，請通過 ibm.com/software/jstart 訪問 jStart Web 頁面。
請注意，jStart 團隊不再從事 XML 項目的工作；小組當前的工作重點是從事 Web 服務。Web 服務以專門的方式使用 XML，通常是通過前面Web
服務中提到的 SOAP、WSDL 和 UDDI 標準來使用 XML。
用 XML 生成多個用戶界面
除了 HTML 界面以外，還規劃了 Java 客戶機界面和 B2B 電子界面。針對所有這些界面，將結構化的 XML 數據轉換成適當的結構和文檔。該服
務首次公開展示時允許一個業務伙伴 — 加拿大證券注冊系統（Canadian Securities Registration Systems）使用安全套接字層（SSL）提交
XML 事務數據。然后將該 XML 事務數據轉換成用于后端事務的適當格式。
最終結果是馬尼托巴省能夠創建一個靈活的新應用程序，并且他們的最終用戶可以更方便更快捷地訪問財產注冊中心。因為該省使用 XML 作為數
據格式，所以政府 IT 團隊在設計新界面和新訪問方法時有極大的靈活性。最棒的是，根本不必更改后端系統。
第一聯合銀行（First Union）使用 XML
第一聯合銀行（美國最大的銀行之一）正在使用 Java 和 XML 重新設計它的許多應用程序。和大多數大公司一樣，它有一個異構環境，有
OS/390、AIX、Solaris、HP/9000 以及 Windows NT 服務器和 Windows NT、Windows 98、Solaris 和 AIX 客戶機。在這種環境下，第一聯合銀
行選擇 Java 作為獨立于平臺的代碼，選擇 XML 作為獨立于平臺的數據。
用 Web 服務來幫忙！
為了解決這些問題，Hewitt 和 jStart 團隊共同努力構建 Web 服務來滿足 Hewitt 客戶的需要。Web 服務是一種以許多有趣方式使用 XML 的新
型應用程序：
首先，Web 服務通常使用 SOAP，這是一個用于將 XML 數據從一處移至另一處的 XML 標準。
其次，Web 服務提供的接口（方法名稱、參數和數據類型等）是用 XML 描述的。
再次，Web 服務的描述可以存儲在 UDDI 注冊中心，或從注冊中心檢索；所有進出該注冊中心的信息都格式化為 XML。
最后，Web 服務提供的數據本身就是 XML 數據。
Hewitt 已經開發出兩個應用程序，它們都證明了自己以更靈活的方式傳遞數據的能力：
使用 Secure Participant Mailbox，經授權的用戶可以請求包含關于退休和其它員工福利的個性化信息的報告。
使用 Retirement Access B2B Connection，經授權的用戶可以獲得客戶的 401(k) 財務信息的詳細情況。
這些應用程序都從現有的舊系統檢索數據，使用 XML 格式化數據，然后在 Web 上傳遞格式化的信息。因為這些應用程序構建于開放標準之上，
所以 Hewitt 可以快速地完成它們的開發。最妙的是，這些應用程序的靈活性使 Hewitt 從其競爭對手中脫穎而出。
“我們把 Web 服務看作一種工具，它通過無所不在的數據網絡，對我們參與者的業務服務和數據提供一種開放、非專有的訪問。”Hewitt 首席
技術決策專家 Tim Hilgenberg 這樣說道。最終結果是：Hewitt 用較低的成本較快地開發出更靈活的應用程序，客戶們能夠更好地訪問他們的數
據，并且不必更改 Hewitt 現有的舊應用程序。
案例研究總結
在所有這些案例研究中，各公司都使用 XML 來創建獨立于系統的數據格式。XML 文檔可以表示那些可以從一個系統或過程移到另一個的結構化數
據。當前端和后端應用程序更改時，XML 可以在它們之間移動而保持不變。更妙的是，當越來越多的前端和后端應用程序添加進來時，XML 的使
用將現有應用程序與任何更改都隔離起來。當 Web 服務變得越來越普遍時，XML 還將用來傳輸數據。
建議和參考資料
行動起來！
此時此刻，我希望您已經相信 XML 是移動和操作結構化數據的最佳方法。如果您現在還沒有使用 XML，您該如何開始呢？下面是一些建議：
確定您要將什么數據轉換成 XML。通常這是需要從一個系統移到另一個系統的數據，或必須轉換成不同格式的數據。
了解是否有現有的 XML 標準。如果您正在研究很常見的數據，例如采購訂單、醫療記錄或股票報價，則很可能已經有人為那些數據定義了 XML
標準。
了解您現有的工具是否支持 XML。如果您正在使用數據庫軟件包、電子表格或其它數據管理工具的最新版本，則您的現有工具（或其升級版本）
很可能可以使用 XML 作為輸入或輸出格式。
學習如何構建基于 XML 的應用程序。您需要理解您的數據現在是如何存儲的，需要如何轉換它，以及如何將您的 XML 開發工作與現有的應用程
wxxmcol/ 找到他所有專欄文章的最新列表。
加入適當的標準組織。考慮加入象萬維網協會（W3C）這樣的組織，以及象 HR-XML.org 這樣特定于業界的組織。成為這些組織的成員將有助于您
跟蹤業界中所發生的事件，而且使您有機會塑造 XML 標準的未來。
避免專有產品的詭計。在開發工作中僅使用基于標準的技術很重要；抵制為您提供所謂改進的供應商的誘惑。XML 的優點之一是您對數據有完全
的控制權。一旦它受到某個專有數據格式的限制，您就失去了極大的控制權。
聯系 jStart 團隊。如果您認為您的企業可以使用 jStart 約定模型，請與該團隊聯系以了解您可能得到什么服務？
關注 developerWorks。我們的 XML 專區有涉及各種 XML 主題的數千頁內容，包括 DTD 和模式開發、XML 編程和創建 XSLT 樣式表。
參考資料
下面是一些可以幫助您開始的參考資料：
dW XML 專區是 XML 參考資料的“一站式商店”。請參閱 www-106.ibm.com/developerworks/xml 以獲取您一直希望了解的有關 XML 的內容。
XML 工具： developerWorks 有一個系列的“Fill your XML toolbox”文章，它們描述用于各種語言的 XML 編程工具：
C/C++：請在 www-106.ibm.com/developerworks/library/x-ctlbx.html（developerWorks，2001 年 9 月）參閱 Rick Parrish 的文章。
Java：請在 www-106.ibm.com/developerworks/library/java-xml-toolkit/index.html（developerWorks，2000 年 5 月）參閱 Doug Tidwell
的文章。
Perl：請在 www-106.ibm.com/developerworks/library/perl-xml-toolkit/index.html（developerWorks，2001 年 6 月）參閱 Parand Tony
Darugar 的文章。
PHP：請在 www-106.ibm.com/developerworks/library/php-xml-toolkit.html（developerWorks，2000 年 6 月）參閱 Craig Knudsen 的文章
。
除了這些文章以外，請在 www-106.ibm.com/developerworks/library/l-pxml.html 參閱 David Mertz 在其“Charming Python: Revisiting
XML tools for Python”文章中對 Python XML 工具的評論。
veloperworks/education.nsf/dw/xml-onlinecourse-bytitle 以獲得最新的列表。
IBM 的 jStart 團隊：jStart 團隊使用新技術（例如 XML Web 服務）以非常低的成本幫助客戶構建解決方案。作為回報，那些客戶同意讓 IBM
將他們的項目作為案例研究公布。要了解更多信息，請參閱 ibm.com/software/jstart。
XML 標準：下面是本教程中提到的所有 XML 標準的字母順序列表。
DOM，文檔對象模型：
核心規范： w3.org/TR/DOM-Level-2-Core/
事件規范： w3.org/TR/DOM-Level-2-Events/
樣式規范： w3.org/TR/DOM-Level-2-Style/
遍歷和范圍規范： w3.org/TR/DOM-Level-2-Traversal-Range/
視圖規范： w3.org/TR/DOM-Level-2-Views/
HR-XML.org，人力資源 XML 協會（Human Resources XML Consortium）：hr-xml.org
JAXP，用于 XML 解析的 Java API（Java API for XML Parsing）：java.sun.com/xml/jaxp/
JDOM，不代表任何縮寫形式：jdom.org/
SAX，用于 XML 的簡單 API（Simple API for XML）：saxproject.org/
SMIL，同步多媒體集成語言（Synchronized Multimedia Integration Language）：
www.w3.org/TR/smil20/SOAP，過去用于代表簡單對象訪問協議（Simple Object Access Protocol），但現在正式不代表任何縮寫形式：w3.org/TR/SOAP/
SVG，可伸縮向量圖（Scalable Vector Graphics）：
www.w3.org/TR/SVG/UDDI，統一描述、發現和集成協議（Universal Description, Discovery, and Integration Protocol）：uddi.org
WSDL，Web 服務描述語言（Web Services Description Language）：w3.org/TR/wsdl（結尾沒有斜杠符號）
XLink，XML 鏈接語言（XML Linking Language）：w3.org/TR/xlink/
XML，最基礎的標準：w3.org/TR/REC-xml
XML 數字簽名（XML Digital Signature）：w3.org/TR/xmldsig-core/
XML 加密（XML Encryption）：w3.org/TR/xmlenc-core/
XML 名稱空間（XML Namespaces）：w3.org/TR/REC-xml-names/
DTD 和模式的 XML 資源庫（XML Repository）：xml.org/xml/registry.jsp
XML Schema：
第 0 部分 — 入門：w3.org/TR/xmlschema-0
第 1 部分 — 文檔結構：w3.org/TR/xmlschema-1
第 2 部分 — 數據類型：w3.org/TR/xmlschema-2
XPath，XML 路徑語言（XML Path Language）：w3.org/TR/xpath（結尾沒有斜杠符號）
XPointer，XML 指針語言（XML Pointer Language）：
www.w3.org/TR/xptr/XSL-FO，用于格式化對象的可擴展樣式表語言（Extensible Stylesheet Language for Formatting Objects）：w3.org/TR/xsl/
XSLT，可擴展樣式表語言（Extensible Stylesheet Language）：w3.org/TR/xslt（結尾沒有斜杠符號）
有關 JDOM 的更多信息，請參閱以下 developerWorks 文章：