本篇文章更新時間：2026/03/15
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
XML 為何在現代軟體還活得好好的？讀《XML is a Cheap DSL》的一些思考
編輯前言：這篇文章的作者從 IRS（美國國稅局）最新開源的 Tax Withholding Estimator（TWE）專案談起，反思為什麼在 2026 年的今天，XML 竟然成了構建稅務邏輯的最佳選擇。這篇筆記整理了文章重點與筆者自己的延伸思考。
文章來源：XML is a Cheap DSL
核心觀點 (Key Takeaways)
- XML 可能笨重、冗長，但對於跨平台的「宣告式邏輯 DSL」來說，它依然是成本最低、可移植性最高的方案。
- 稅務邏輯非常適合用宣告式（declarative）方式描述，而非一般程式語言的命令式（imperative）寫法。
- XML 帶來的「可解析性」、「跨語言工具鏈」、「審計能力」與「可追溯性」遠遠超過 JSON 或 YAML 能提供的。
深入解析
作者從 TWE 的 Fact Dictionary 談起。這是一個用 XML 描述美國稅法邏輯的 DSL。所有的稅務計算規則並不是用 JavaScript、Scala 或 Python 寫的，而是用 XML 這種結構化標記語言宣告出來的。例如：
"This fact describes a /totalOwed fact that’s derived by subtracting /totalPayments from /totalTax."
看起來冗長，但事實上邏輯清晰且極具一致性。
1. 為什麼不用更自然的 JavaScript？
作者展示了用 JS 寫的邏輯雖然更短，但會產生兩個問題：
- 命令式語言會隱藏中間狀態，讓「追溯邏輯」變得困難。
- 執行順序會影響邏輯，例如 getInput() 必須在某一步被呼叫後才能算下一步。
相比之下，XML：
- 不描述步驟，而是描述「事實彼此的依賴關係」。
- Fact Graph 引擎會自動決定執行順序。
- 每個中間值都是可查詢、可審計的節點。
這種透明度對稅務系統尤其重要，因為稅務計算牽涉「數百個中間值」，沒有明確抽象會非常難 debug。
2. JSON 聽起來是更現代的選擇，為何失敗？
作者示範了用 JSON 描述同一段邏輯，看起來立刻變得更糟：
- JSON 缺乏型別與結構的語義。
- 嵌套表達式極度冗長，因為每個部分都要「type」、「kind」地描述。
- 多層巢狀的情況下，JSON 基本上不適合人類閱讀。
對比 XML：「語意藏在標籤裡」，自然得多。
3. YAML 更簡潔，但為何完全不適合？
作者引用一句原文金句：
“whatever you do, don’t try to express the logic of the Internal Revenue Code as YAML”
原因不難想像：YAML 對結構、語意、縮排敏感，不適合構建複雜、嚴格的 DSL。
4. 那為什麼不用 Lisp 的 S-expressions 或 Prolog？
作者承認那些語法其實更漂亮、更抽象，對複雜邏輯也更合適。然而，他點破了決定性關鍵：
XML 給你一套「跨所有語言都能使用的工具鏈」。
只要你選 XML：
- 可以用 XPath 查詢
- 可以用 shell 工具簡單處理
- 可以透過轉換輕鬆生成 Prolog / Lisp / JSON
- 可以在任何語言、任何平台解析
這就是作者說的：
“XML is a great canonical, cross-platform data format.”
也因此，用 XML 做 DSL 是成本最低且可擴展性最好的做法。
筆者心得與啟發
老實說，讀完這篇文章後我重新認識了 XML。過去我也像作者一樣，把 XML 和過時技術畫上等號。但文章讓我重新思考一件事：
一個語言是否好用，不在於語法有多潮，而在於它是否能最有效率地解決你手上的問題。
在 TWE 的案例裡，需求包含：
- 可審計性
- 可追溯性
- 一致性
- 跨平台工具鏈
- 類似知識圖譜的結構
XML 在這些面向的成本／效益比，竟然是所有選項之中最高的。甚至讓本文作者從原本想推行 S-expressions，到最後心甘情願擁抱 XML。
那我從這篇文章得到了什麼啟發？
- 選技術不應從喜好、風格出發，而要從「最終價值」出發。
- 宣告式模型的威力遠超過一般工程師的直覺。
- 工具鏈的普及度遠比語法美不美重要。
下次當我需要為一個跨團隊、跨平台、長期維護的邏輯系統選擇表達方式時，XML 可能會回到我的選項列表中，至少不再被第一時間排除。
對 XML 程式語言 DSL 的興趣，我想我真的被重新點燃了。