本專欄目前的主題是語義透明性：正確解釋 XML 文檔內容的能力。語義透明性可能是 XML 建模最重要的方面。這是一系列文章中的第一篇，我們將考察語義透明性的很多不同方法，討論它們對使用 XML 的開發人員來說意味著什麼。
這是 Thinking XML 專欄的第 30 期。從第一篇文章至今差不多有四個年頭了，回想一下，時間的飛逝和事情的發展真是令人吃驚。與 XML 有關的活動非常之多，我希望有些已經在本專欄的主題中出現過了。這些活動和 XML 在知識管理技術中的應用特別密切，這也是本專欄所關注的焦點。2001 年 2 月份發表的第一期文章中討論了語義透明性的目標，我認為這是 XML 數據建模最重要的方面。本專欄中已經考察了實現語義透明的不同方法。我將通過幾篇文章介紹關於語義透明性的一些有趣的方法和技術，闡明我對這一領域進展的看法，本文是第 1 部分。這一系列的文章由三部分組成：
正式的模式，非正式的透明性
對於 XML 最常見的一種誤解是，認為只要定義了模式，別人就會知道如何處理 XML 實例，如何與您的系統交互。有可能這樣，但這要看模式是如何編輯的，一般來說，這不是由於模式語言本身的特性造成的。清單 1 是一個示例 RELAX NG 模式（緊湊語法）的片段：
清單 1. 使用注釋提供語義線索的 RELAX NG 模式
namespace dc = "http://purl.org/dc/elements/1.1/"
element purchase-order
{
dc:description [ "General purpose purchase order for merchandise" ]
attribute id {
dc:description [ "Unique identifIEr for the purchase order" ]
text
}
#The rest of the schema here
}
如果不熟悉 RELAX NG，上面的第一行是 Dublin Core 的名稱空間聲明，這是一種非常流行的詞匯表，用於諸如標題、描述、性質和其他類似庫的元數據元素。第二行定義了一個名為 purchase-order 的元素。以 dc:description 開始的行是一個注釋，使用了前面聲明的名稱空間前綴，指出注釋的內容將提供符合 Dublin Core 描述元素的信息。後面的 4 行定義了一個名為 id 的屬性，其值是普通文本。這個屬性定義有自己的注釋，指出了該屬性的意義。最後一行是一個評注。注意，該例中使用注釋提供了幫助理解這個模式語義的重要信息，而用評注傳達附帶的信息。<purchase-order id="123"/> 就是符合該模式的文檔。
如果清單 1 是 Acme Organization 采用的訂單模式，那麼獨立的 Zenith Organization 也許會采用清單 2 所示的模式。
清單 2. 和清單 1 類似的 RELAX NG 模式
namespace dc = "http://purl.org/dc/elements/1.1/"
element po
{
dc:description [ "Simple purchase order" ]
attribute number {
dc:description [ "Number for identifying the purchase order" ]
text
}
#The rest of the schema here
}
注意，其中的注釋是類似的，而具體的元素和屬性名卻不同。相應的文檔可能是 <po number="123"/>。看過上面兩個模式的人可以從注釋中發現：一個文檔中的 purchase-order 元素與另一個文檔中的 po 元素是等價的，而 id 屬性和 number 屬性也是等價的。這樣就通過非正式的方式得到了語義透明性。人們必須使用不嚴密的自然語言技巧來理解注釋，而不是使用某種嚴格的、沒有歧義的定義。
問題在於這個過程沒有可伸縮性。在上面的例子中，兩個詞匯表的數據元素之間存在簡單的一對一映射，即使不經意地閱讀這些注釋，也很容易對它們作出比較。實際的情況中常常涉及更復雜的模式，映射關系不那麼容易預測，注釋和其他非正式描述中也存在細微的差別。這種情況下，通過自然語言的模式注釋來獲得語義透明性可能非常困難。
DTD 沒有直接提供注釋，但其他流行的模式語言提供了注釋，如 RELAX NG、W3C XML Schema (WXS) 和 Schematron。這些語言中可以構造供機器識別的注釋，為語義透明性提供更可靠的方法。後面的文章中將介紹一些這方面的技術。不幸的是，這種技術沒有經過很好的講解、討論，甚至分析，部分原因在於研究 XML 的人們錯誤地認為語義透明性並不是一個緊迫的問題，或者認為 XML 本身已經具備了語義透明性。從我的觀點來看，有一件特殊的事情分散了人們對語義透明性的注意。
非凡的障眼法
XML 專家認識到了用上述這種非正式描述提供語義透明性的弱點。隨著 XML 1.0 獲得成功，增加這類設施的嘗試一直是接下來 要討論的問題之一，其他要討論的問題包括鏈接、處理慣例，等等。最初，嘗試解決這些問題的人們劃分成不同的陣營。最突出的一個陣營是那些熟悉主流編程語言和數據庫管理系統的老手，他們認為形式化 XML 文檔基礎的最佳方式就是常見的數據類型化技術，這是他們最熟悉的。他們習慣於按照組成主流源和數據庫系統靜態數據類型化的最初設想來思考所有的語義。他們認為，只要將 XML 緊緊綁定到他們熟悉的隱喻上，就能夠解決建模問題。
數據類型化的支持者可能把清單 2 中的模式修改成清單 3 所示的版本。
清單 3. 使用 WXS 數據類型的 RELAX NG 模式
namespace dc = "http://purl.org/dc/elements/1.1/"
element po
{
dc:description [ "Simple purchase order" ]
attribute number {
dc:description [ "Number for identifying the purchase order" ]
xsd:int
}
#The rest of the schema here
}
這一次，WXS 數據類型被指定給了該屬性，這反映出模式的設計人員認為訂單號應該限制為一個整數。這就是 xsd:int 這一行的含義。顯然增加的信息與模式的正確解釋沒有多少關系。客觀地說，即使數據類型化的鼓吹者也不認為達到了目標，但是他們宣稱增加的這一點精確性，使處理工具能夠對 XML 實例作其他某種形式的推理和分析。我懷疑這種聲明的可信性，但相信它花費了 XML 社區的很多精力，讓該社區成員致力於不會有結果的數據類型妄想。這些精力本來可以在語義透明性問題上發揮更大的作用。
更直接的問題是，當人們反射性地使用數據類型時，常常以無法預料的方式降低靈活性。比方說，如果使用清單 3 所示模式的 Zenith Organization 希望和使用清單 1 所示模式的 Acme Organization 交易，那麼現在問題進一步復雜化了，因為一個模式將 PO 看作整數，而另一個則將其視為普通文本。這種錯誤匹配反映在很多數據類型感知的工具中。匹配錯誤在任何集成項目中都是不可避免的，但是在這種情況下，嚴格數據類型化所帶來的好處還抵不上靈活性方面的損失。
這對開發人員意味著什麼呢？我並不是說不應該使用模式數據類型，但不要作為一種反射行為來使用。可以用它們標記經過深思熟慮的、在系統的整個生存期中都是合理的約束。不要被數據類型化先入為主，以致於忘記考慮如何澄清與 XML 詞匯表有關的更一般的語義。
我在 Amara XML 工具箱中增加了根據 XML 節點中的文本范式推斷數據類型的功能，這是為 Python 編程語言開發的一種 XML 處理庫。我謹慎地將這種類型推斷設成可選的功能，認為如果將其作為所有處理工具鏈條的基礎可能是危險的。我還通過某種聲明性的方法，使用戶能夠使用 Jeni Tennison 的 Data Type Library Language（DTLL，請參閱參考資料）自定義數據類型。 DTLL 幫助進一步明確了這一事實，即 XML 中的數據類型化只不過是對文本的一種特殊解釋。這就是問題的症結所在：XML 是文本，而且只是文本。其他層次如數據類型化只不過是對文本的解釋（而且是可選的解釋）。如果沒有看到這一點，就會陷入各種沒有預料到的麻煩之中。
結束語
無論能否帶來語義透明性，為模式編寫良好的注釋都非常重要。對於維護單獨的數據詞典文檔，像數據庫管理員所熟悉的那樣，甚至注釋就足夠用了。對於模式中使用的每個項，數據詞典提供的描述非正式地填充了這些項的語義。一旦認識到文本在 XML 中至高無上的地位，語義透明性的重要性就很清楚了。因為所有 XML 處理都歸結為解釋語言的問題，最重要的是找到一種方法減少解釋的歧義性。如果您對模式、模式注釋、數據類型化或者相關主題有什麼想法，請提交到 Thinking XML 討論論壇 和我們分享。