當今計算世界趨向於任何所有正式規范和數據描述都使用 XML。本文作者 － XML 的忠實擁護者 － 提出了一個亵渎神明的問題：“XML 極權主義是個好主意嗎？”在這篇觀點性文章中，Terence Parr，jGuru 的共同創始人，演示了 XML 形成的糟糕的人機界面。他還提出了一些問題，這些問題是讓您自己決定 XML 是否甚至適合於項目的程序對程序接口所需。
記得剪貼前生活的樣子嗎？（正如我的朋友 Gary Funck 所說，“如果您不是老到記不得的話……那麼對您來說很好”）。每個程序以不同方式存儲數據，並且很少希望將大量數據送到另一個應用程序，當然肯定不會送到另一個正在運行的程序。在現代操作系統中，粘貼緩沖區以標准方式保持數據，而每個程序覺得合適，就可自由地解釋緩沖區數據。例如，可以從數據庫程序中剪切一段數據並有意義地粘貼到圖形程序中。
類似的，在因特網上的程序之間和機器之間，有一種稱之為 XML 的共享數據的標准方式。如果沒有 XML 或類似標准，那麼兩個程序就不可能共享信息 － 出於數據可移植性，用來格式化數據的基本語法必須相同。當然，您可能無法解釋這些數據，但至少能將它們讀入。看一下如 SOAP 和 XBean 這樣的技術，了解 XML 是如何促進互操作性的（請參閱參考資料）。
既然就這個問題我們已經達成了共識，即，XML 是，還是應該是，程序數據互換的公共語言，那麼我想反過來討論一下：什麼時候使用 XML 沒有意義？首先，需要提醒您的是，XML 看起來象什麼以及它與其它數據格式有何不同。如果在這種背景條件下，那麼當確定項目數據格式時，我提出一系列可以證明是有用的問題。最後，我將演示我的主要建議：XML 形成了糟糕的人機界面。
您說“date-uh”，我說“dat-uh”
XML 是一種突出數據結構的手段，對於計算機程序，可使它檢查該數據更容易。當然，它不是第一種數據格式。古老的逗號分割值（CSV）格式一直使用了幾十年來描述成行的數據。例如，這裡有可能描述三個日期記錄的三行整數：
8, 17, 1964
12, 30, 1975
9, 1, 1970
CSV 在可讀性和實現簡單性方面很難被擊敗（想必您必須在第一節計算機課編寫程序來讀取 CSV 數據）。問題是 CSV 實行嚴格的數據次序，並且 CSV 不能方便地描述嵌套結構和不同類型的元素。添加花括號以表示嵌套、聚合數據（如 C 和 VRML 中）的做法改善了可表達性，同時使數據具有可讀性。例如，要將每行數據與一個標識符相關聯，您可能編寫：
{{8, 17, 1964}, instructor}
{{12, 30, 1975}, student}
{{9, 1, 1970}, student}
這種格式仍然相當易於進行語法分析，但它繼續實行嚴格的數據次序。解決次序局限性的方法是標記所有數據，譬如：
{date={m=8, d=17, y=1964}, title=instructor}
{date={d=30, m=12, y=1975}, title=student}
{title=student, date={m=9, d=1, y=1970}}
雖然現在數據是位置無關的（您可以看見我已經將一些元素弄混了)，但冗余的標簽增加了存儲成本並使得更難對它進行語法分析。
當前，我們大多數會按如下以 XML 形式編碼數據：
<record>
<date><m>8</m> <d>17</d> <y>1964</y></date> <title>instructor</title>
</record>
<record>
<date><d>30</d> <m>12</m>, <y>1975</y></date> <title>student</title>
</record>
<record>
<title>student</title> <date><m>9</m> <d>1</d> <y>1970</y></date>
</record>
我的觀點是有無數的描述格式（語言），帶有不同程度的可讀性、實現的方便、效率、普遍性和表示方式等等。雖然如此, 我們還是要迅速地集中於完全的 XML 格式的支配。
XML 復雜性和程序間通信
Web 的蓬勃發展和對 HTML 的普遍熟悉把我們領向 XML，它實際只是另一種結構化數據格式。遺憾的是，我們對數據標記得越多，對計算機時間和空間效率的影響就越大。另一方面，數據是任何帶 XML 語法分析器的程序都可以讀取的標准形式。針對不同情況，需要在簡單性和標准化之間解決折衷。當拿不定主意時，也許應該使用 XML。另一個顯而易見的規則是，如果您的數據是高度結構化的，那麼用 XML。例如，當將 jGuru FAQ 內容（請參閱參考資料 ）導出到我們的伙伴時，提供 XML 數據文件。相反，如果數據不是那麼復雜，XML 也許不是最好的選擇。通過提一些簡單的問題，通常可以為您的程序在 XML 和另一種數據格式之間做出決定。對於本節中四個問題裡的任何一個，如果您回答“是”，您可以考慮用更簡單的格式來替換標准的 XML 數據。
XML 語法分析器所占比重遠遠超過了程序的其余部分？
如果編程任務和相關數據相當簡單，那麼為什麼用龐大的 XML 語法分析器以及從結果樹中拽出數據所必須的粘接代碼，來增添您自己負擔呢？請記住，您的目的是完成任務，而不是自己擺弄 DOM 樹。程序中組件越多，越容易出現故障。現在，另一方面，如果程序中已經有 XML 語法分析器，那不妨使用它以便在程序中保持一致。
同樣回想一下，大多數編程語言對於非 XML 數據格式有小的、內置的語法分析器。例如，Java 有標准方式來讀入屬性文件，還有易於從簡單數據字符