XML 在信息處理中已經變得無處不在，滲透到從傳統發布到業務事務再到 Twitter 的所有事物中。“XML 很簡單！” 這種認識往往意味著，面向 XML 應用程序的標記組設計往往沒有面向信息集合的標記組設計那麼理想。低劣的信息設計可能會使信息集合的操作和呈現所需的代碼更復雜。幸運的是，在最開始多做一些工作能夠簡化以後的開發工作。
常用縮略詞
IEC：國際電子技術委員會
ISO：國際標准化組織
SGML：標准通用標記語言
W3C：萬維網聯盟
XML：可擴展標記語言
XSLT：可擴展樣式表語言轉換
設計一個信息結構可以歸結為三個基本問題：
一個信息集合的有用 片段是什麼？
這些片段之間的關系如何？
關於這些片段還有其他需要了解的嗎？
我們來檢查一個常見信息集合，並考慮數據處理中可能用到的 XML 結構。
檢查一條地址記錄
一條地址記錄可能以多種不同形式、在多個不同環境中出現：可能在另一條信息集合中單獨出現，也可能作為存儲在數據庫中的集合的成員，以標簽形式查詢或打印。一條典型的地址記錄可能如 清單 1 所示。
清單 1. 一條姓名和地址記錄
John Q. Public
1234 Main Street
Anytown, Anystate 54321-6789
從 XML 角度看，這條記錄的結構可以非常簡單，如 清單 2 所示。
清單 2. 使用簡單標記的姓名和地址記錄
<address_rec>
<line>John Q. Public</line>
<line>1234 Main Street</line>
<line>Anytown, Anystate 54321-6789</line>
</address_rec>
也可以很復雜，如 清單 3 所示。
清單 3. 使用復雜標記的姓名和地址記錄
<address_rec>
<name>
<given_name>John</given_name>
<middle>Q.</middle>
<family_name>Public</family_name>
</name>
<address>
<street>1234 Main Street</street>
<city>Anytown</city>
<state>Anystate</state>
<zip_code>54321-6789</zip_code>
</address>
</address_rec>
您可以進一步細化這個結構，標記標點（句點、逗號和短橫線）或將郵政編碼分為兩部分。您還可以添加信息，比如電話號碼、傳真號、電子郵件地址或網址。
確定一條地址記錄的要求
現在停下來回想一下此前提出的基本問題。什麼是有用 片段？要確定有用片段，首先需要確定數據的要求和目的。您將：
打印標簽？
根據姓氏或郵政編碼排序？
搜索姓名、城市或州？
當您把數據分割為有用片段時，如何使用數據將影響您的選擇。因此，分析一個信息集合的第一步將是識別關鍵要求。定義一組容器（或根據現有標准選擇一個容器組）應該由信息集合的特定使用需求驅動。將一個表分解為一些行和列也許還不夠 — 一個關系表的記錄結構也許不能捕獲一些有用的組合。
一個信息集合的要求通常可以劃分為三個類別：
必須擁有。如果這些要求沒有得到滿足，項目將會失敗。
最好擁有。如果這些要求能夠滿足，您就能夠向用戶提供更多價值。
如果資源不受限（“Blue Sky” 選項）。這些是超出當前項目范圍的 “很酷” 的特性。
根據目前的預算和最後期限，“必須擁有” 的要求是預先確定的；一個項目也可以選擇一些 “最好擁有” 的要求。也就是說，最好記錄所有已識別的要求 — 甚至是 Blue Sky 要求。某個小組認為是 Blue Sky 的要求可能是一個 “必須擁有” 的要求的副產品。
定義並改進地址記錄模型
一個 XML 結構通常由元素和屬性組成 — 在最基本的層面上，元素 是數據容器，屬性 是數據容器的標簽。當您首次為一個信息集合構造一個 XML 模型時，通常應將這個信息集合定義為一個元素集合並使用屬性來改進這個元素結構。
在這個地址記錄示例中，簡單結構和復雜結構都只使用元素來表達；可以使用屬性來改進和增強這個結構 — 例如，通過排序鍵。如果您開發自己的詞匯表而不是采用一個標准詞匯表，那麼 XML 結構以及屬性和元素的選擇完全由您決定。能否使用一些元素或屬性來標識有用信息片段受到少數幾個技術約束的限制，除此之外，您可以完全靈活地選擇。
檢查一下來自 清單 3 的更復雜的示例，這個復雜示例似乎滿足了目前確定的所有要求：
可以打印。事實上，每條記錄可以打印為三行：一行打印 name 元素，一行打印地址的 street 元素，另外一行打印地址的 city、state 和 zip code 元素。
您已經標識了 surname 和 zip code，因此您可以使用這些元素的內容來對 address_rec 元素排序。
您已經標識了姓名及其組成，以及城市和州，因此，您可以搜索字符串並將結果限制到這些元素。
看起來您已經滿足了所有初始要求。盡管可以進一步增強這個結構，但現在可以認為工作已經告一段落。記住這條古老的諺語：能夠做並不意味著應該做。
您會如何增強這個結構呢？數據庫喜歡使用鍵，因此，添加一個記錄鍵到每個 address_rec 組件，如 清單 4 所示。
清單 4. 帶有一個 key 屬性的姓名和地址記錄
<address_rec key="1234">
<name>
<given_name>John</given_name>
<middle>Q.</middle>
<family_name>Public</family_name>
</name>
<address>
<street>1234 Main Street</street>
<city>Anytown</city>
<state>Anystate</state>
<zip_code>54321-6789</zip_code>
</address>
</address_rec>
如果您從一個數據庫提取一些記錄來創建 XML 文檔，您可以將數據庫鍵直接傳輸到 address_rec 元素的 key 屬性。key 屬性的作用是充當 address_rec 容器上的一個標簽，為記錄提供一個惟一的標識符。
盡管您可能不想打印虛構標簽上的電話號碼，但您可以捕獲其他類型的聯系信息，將其傳輸到您的 address_rec XML 文檔。您可以在 XML 結構中包含電話號碼和其他形式的電子聯系信息，如 清單 5 所示。
清單 5. 帶有其他聯系信息的姓名和地址記錄
<address_rec key="1234">
<name>
<given_name>John</given_name>
<middle>Q.</middle>
<family_name>Public</family_name>
</name>
<address>
<street>1234 Main Street</street>
<city>Anytown</city>
<state>Anystate</state>
<zip_code>54321-6789</zip_code>
</address>
<phone>316-555-1234</phone>
<email>john@mydomain.com</email>
<web>http://www.mydomain.com/john</web>
</address_rec>
如果您的這位神秘的 John Q. Public 在計算機上花費的時間和我一樣多，他也許擁有幾個聯系點。您可以為每個聯系點創建一個元素，也可以使用帶有一個修飾屬性的單個重復元素來標識他的每個地址。我們將嘗試使用後者。您還可以允許使用多個電話號碼，如 清單 6 所示。
清單 6. 帶有更多聯系信息的姓名和地址記錄
<address_rec key="1234">
<name>
<given_name>John</given_name>
<middle>Q.</middle>
<family_name>Public</family_name>
</name>
<address>
<street>1234 Main Street</street>
<city>Anytown</city>
<state>Anystate</state>
<zip_code>54321-6789</zip_code>
</address>
<phone type="home">316-555-1234</phone>
<phone type="fax">316-555-1235</phone>
<phone type="mobile">316-555-1236</phone>
<web type="email">john@mydomain.com</web>
<web type="email">john@myworkdomain.com</web>
<web type="homepage">http://www.mydomain.com/john</web>
<web type="twitter">johnqpublic</web>
</address_rec>
元素和屬性的選擇是任意的（除非您需要適應其他人的結構），type 屬性的值也是任意的。姓名和值的選擇也可以通過應用程序或系統的需求驅動。
這個過程最重要的部分是滿足要求：如果您能夠完成預定的任務，那麼您就出色地完成了工作。
模式和驗證：要求還是增強？
當您確定一個信息集合的有用片段並定義和改進模型後，下一個問題是：工作完成了嗎？對於某些 XML 應用程序，標識有用信息塊並使用那些添加了標簽的信息片段來驅動所需的任何後續流程就足夠了。
至此，您已經創建了 “格式良好的” XML 文檔：這些文檔遵循非常少的規則，適用多種不同的處理系統。對於許多應用程序而言，格式良好的 XML 文檔就可能夠用了。
但是，如果您的某些要求需要滿足一組更嚴格的規則，那又該怎麼辦呢？XML 文檔可以被驗證 — 即由一個程序針對一組更特定的規則和關系進行檢查 — 您可以使用一種或多種正式驗證語言來編寫一個驗證框架。常用驗證語言有：
Document Type Definition (DTD)。繼承自 SGML (ISO 8879, "Standard Generalized Markup Language")，DTDs 是最古老的驗證語言，定義為 W3C 的 XML Recommendation 的一部分。
W3C XML Schema。這種語言由 W3C 開發並被廣泛實現，包含數據類型化（datatype）並被編寫為一個 XML 文檔。
RELAX NG。這種語言最初由 Organization for Advancement of Structured Information Standards (OASIS) 開發，之後被定義為一個 ISO 標准 — ISO/IEC 19757-2:2008 — 的一部分，它擁有兩種形式：XML 文檔形式和一個緊湊的、非 XML 形式。
可以用 Schematron 表達這些模式語言沒有包含的其他規則，Schematron 是一種基於 XSLT 的驗證語言，用於驗證文檔內容和結構。
模式也可以是一種用於交流理想結構和關系的有用方法 — 特別適用於表單和創作工具等人類交互。它表示信息提供者和信息使用者之間的契約 — “這是我想得到的，這是我期望的組織方式。”
驗證不是一個基於 XML 的應用程序的必要部分，但通常是控制 XML 文檔的創建或對來自其他源的 XML 文檔提供質量控制的有用工具。
您需要一個模式嗎？創建一個模式需要知識、時間和努力：如果它不屬於您正在開發的應用程序或系統的一個有用部分，創建一個模式也許是浪費資源。考慮以下原則：
您的信息是機器生成的還是人工生成的？模式是交流信息集的結構和內容需求的有用方法 — 對創作工具尤其如此。
包含的信息來自您無法控制的源嗎？如果是這樣，那麼模式可以確認外部信息源提供的 XML 文檔是否遵守您期望接收的結構。
您需要驗證嗎？您的系統或客戶機可能需要將驗證作為系統的一部分，正式驗證需要不同形式的模式。
您的處理鏈中的工具需要模式嗎？用於操作或呈現 XML 文檔的工具可能不需要模式，但創作工具也許需要。
記住，那條古老的諺語在這裡也適用：能夠做 並不意味著應該做。有時，為一個特殊信息集合開發模式可能沒有必要而且沒什麼用，或者因為工作量巨大而變得不可能。有用的模式適合於其中的數據相對可預測的應用程序 — 數據集合中的變化越多，需要的模式就越復雜。
結束語：信息分析簡述
您現在應該已經清楚了解了確定一個 XML 信息集合的有用部分的流程：
定義信息集合的要求。
檢查信息集合樣例。
識別滿足要求的信息集合片段和片段之間的關系。
為 XML 應用程序構建堅實的基礎能夠減少您在開發過程中編寫真正聰明（即復雜）的代碼的需求。