XML 是關於靈活性的
不需要詳細研究 XML 起源的長期歷史原因，在開始這個討論話題之前我想再次重申 XML 最初確實是關於靈活性的。XML 提供了一種供應商中立的格式來表示數據。根據對 XML 規范內容和要求的一致理解，應用程序可以輕易生成這種格式，並且其它應用程序也可以方便地使用這種格式。
以更通俗的語言來說，如果您告訴我您使用的是 XML，然後再告訴我您所使用的元素和屬性，我很快就能寫出能讀取和使用 XML 的代碼來。反過來也一樣，如果我向您提供了我的約束模型 (constraint model)(通常為 DTD 或者 XML Schema 格式)，您就能夠很快地操作我的數據。
最初的 API 可以維持這種靈活性
不足為奇，當 XML API 剛開始出現的時候，它們都非常的簡單。最初版本的 Simple API for XML(SAX)和文檔對象模型(Document Object Model，DOM)只具備非常基礎的操作。您可以從某個元素中獲得數據，操作其子元素，找出某個屬性的值等，全部都是這方面的操作。除了處理 XML 的詞匯結構之外，這些 API 並未提供大量的特性。
在 XML 發展的初期，這被認為是件好事。這非常像過去程序員對 C 語言和匯編語言做的一樣，以對計算機中底層的比特和字節維持最大控制，SAX 特別適合於處理原始的 XML 文檔 — 具有基本格式的數據 — 並允許您的程序完成需要的操作，而不需要花費業余時間研究這些 XML API。
然後出現了包裝 API
首次告別低級控制 — 從理論上說實現了開發人員友好的 API — 的是 JAXP，Sun 公司用於處理 XML 的 Java API。最初，JAXP 的目標是從 SAX 和 DOM 代碼中移除一些特定於供應商的信息(涉及到所使用的 XML 解析器)。
然而，為了努力提供一些便利，JAXP 提供了幾個輔助方法(helper method)，從本質上說就是把 SAX 和 DOM 中已有的功能封裝起來。因為 Sun 公司在 Java 市場上影響如此巨大，所以開發人員很快就開始使用這些輔助方法了，並且很少再直接操作 SAX 和 DOM 了 。
程序員仍然需要了解 SAX 的基本原理(如什麼是 ContentHandler 以及如何實現回調方法)，但是 JAXP 抽象出了很多這樣的細節。事實上，要執行特定的動作，如設置一些 SAX 中不常見的詞匯句柄，我們不得不 繞開 JAXP 而直接操作 SAX。
如今又出現了數據綁定，JDOM 和大量的 API
差不多在十年之後(取決於您所使用的日期)，又出現了許多其它種類的 API。除了 SAX、DOM 和 JAXP 之外，我們還可以使用 JDOM、XOM、dom4j、StAX 和一些其它的變體非常直接地操作 XML。一些數據綁定 API，如 Zeus、Castor 和 JAXB 能允許我們在對 XML 沒有多少了解的情況下處理 XML，而不用操作 XML 文檔表示為邏輯數據而不是字符串或其他數據的數據。並且 Eclipse 之類的框架將完成所有這些操作，而您只需指定、單擊和修改 XML 就可以了。從字面上看，有數百種方案可供選擇(使用 XSLT 後我甚至不需關心 XML 的轉換了)。
我們仍然具備靈活性嗎?
掌握了所有可用於操作 XML 的 API 之後，Java 和 XML 程序員似乎具備了前所未有的高度靈活性; 那麼選擇就意味著靈活性嗎?我們稍微質疑一下這一斷言，看它是否真的站得住腳。
解析程序中的靈活性
毫無疑問，我們能夠使用所想要的任何 XML 解析器，任何版本和風格的解析器都可以，只要我們具有某些類文件 — 大多數情況下，這些文件都捆綁在所選的 API 中。因此要方便地從 XML4J 轉換到 Sun 公司的老式 Crimson 解析器再到 apache Xerces(版本 1 或版本 2)是非常簡單的。JAXP 之類的 API 可以很輕松地實現這個過程(盡管我在側欄中指出在所有新 API 出現之前這在 SAX 或 DOM 中就已經可用)，並且在很多數據綁定 API 中，我們甚至完全意識不到正在進行的解析; 解析都隱藏在幕後。因此毫無疑問，我們可以馬上使用任何想要的解析器。解析器中的靈活性被證實。
使用中的靈活性
大量的 XML API 還為我們提供了很多處理數據的方法。使用 SAX 和 DOM，能輕易地獲得文檔中的原始數據; 使用 JAXP 也同樣可行，盡管所支持的數據可能會少一點(我之前提到過必須要執行一些操作才能處理 XML 注釋或 DTD 語法之類的數據)。我們在使用某個數據綁定 API 時，可以在根本上操作 XML 文檔的數據而不需 XML 的修飾。person 元素變成了Person 對象，並且我們能夠使用 getAge() 獲取 age 屬性的值。在很多方面，您可以根據在 XML 文檔中使用數據的方式以及對 XML 的了解程度來選擇 API。因此使用中的靈活性證實無誤。
錯誤處理中的靈活性
這裡遇到了些許麻煩，高級 API 的一些靈活性造成了一些問題。在一些 API 中，如 Sun 的 JAXB 和所提供的數據綁定 API 中，我們都是在 XML 文檔的原始字符串、元素和屬性之上的幾個層次上進行操作的。其結果是，如果文檔中的內容格式不正確，則處理任何問題都無法具備高度的靈活性。一般而言，在遇到某種編組或非編組錯誤時，我們必須要修復 XML 本身並重新運行該過程(或者向調用程序拋出異常，這在本質上是相同的)。但是在真正地修復錯誤並從解析器中獲得詳細信息的方面呢?這確實不屬於高級 API 的范圍。因此，此處出現了一個缺陷。
操作 XML 文檔中的靈活性
上面所提到的使用中的靈活性，看上去可能與操作 XML 文檔中的靈活性是一樣的。其實並非如此; 在很多新興的(有些人會說是易於使用的)API 中，我們是在 XML 文檔中操作數據的 — 然後有時甚至不是作為 XML 而是當作對象或者屬性來進行操作的。操作 XML 文檔本身意味著我們能直接更換、修改或者移除文檔的一部分，並能直接處理元素名稱、屬性甚至注釋和處理指令。
最初看來可能並不是真正需要這一級別的處理和靈活性，但是我們想到了與編程的類比。正如 C 語言和匯編語言使核心編碼器在計算機編程的底層進行工作，特別是 SAX 之類的 API，和程度較輕的 DOM，使核心的 Java 和 XML 程序員幾乎可以隨心所欲地操作 XML 文檔。就像大多數技巧都內建在 C 語言或者匯編語言中，由於這種額外的能力轉化成了真正的速度、性能和一些優化，比起一些高級的 API(如 JAXB 甚至是 JDOM)，使用 SAX 和 DOM 仍然能為有經驗的程序員提供更多的支持。因此，雖然這些高級 API 確確實實提供了大量的優勢，但是它們並沒有為直接操作實際的 XML 文檔提供很多的靈活性。
結束語
就是這樣：我就是想考證究竟有多大的靈活性。顯而易見，這篇文章並不是一篇充滿了運行代碼的技巧文章，因為我想知道這些天來是否有人確實使用了運行的 XML 代碼，以及他們所使用的是哪種(或哪些)API。真的有數百計、數千計或者數萬計的讀者仍然堅持使用 SAX 和 DOM 舒適地編寫著 startProcessingInstruction() 方法，或者完全使用數據綁定和輔助 API 取代了 SAX 和 DOM?我對此非常好奇，大多數 developerWork 的編輯人員同樣好奇。
更重要的是，您是否認為自己仍然能夠控制 XML 呢?我特別要向那些早期就開始處理 XML 的程序員提這個問題，那時 SAX 是快速讀取 XML 的惟一選擇，並且 DOM 是以對象的形式處理 XML 文檔的惟一選擇。您是否發現您自己在一個更高的級別工作?您是否對此滿意?或者是否我們都已成為 Turbo Pascal 程序員，而只有少許人在他們的 ASM 終端上處理堆棧呢?