XML 程式設計思想:XML 建模藝術描述(轉)[@more@]

　　本專欄目前的主題是語義透明性：正確解釋 XML 文件內容的能力。語義透明性可能是 XML 建模最重要的方面。這是一系列文章中的第一篇，我們將考察語義透明性的很多不同方法，討論它們對使用 XML 的開發人員來說意味著什麼。

　　這是 Thinking XML 專欄的第 30 期。從第一篇文章至今差不多有四個年頭了，回想一下，時間的飛逝和事情的發展真是令人吃驚。與 XML 有關的活動非常之多，我希望有些已經在本專欄的主題中出現過了。這些活動和 XML 在知識管理技術中的應用特別密切，這也是本專欄所關注的焦點。2001 年 2 月份發表的第一期文章中討論了語義透明性的目標，我認為這是 XML 資料建模最重要的方面。本專欄中已經考察了實現語義透明的不同方法。我將透過幾篇文章介紹關於語義透明性的一些有趣的方法和技術，闡明我對這一領域進展的看法，本文是第 1 部分。這一系列的文章由三部分組成：

在正式的模式中使用非正式的描述（本文）。
對於自上而下的語義透明性使用模式標準。
對於自下而上的語義透明性在模式中使用語義錨（anchor）。

　　正式的模式，非正式的透明性

　　對於 XML 最常見的一種誤解是，認為只要定義了模式，別人就會知道如何處理 XML 例項，如何與您的系統互動。有可能這樣，但這要看模式是如何編輯的，一般來說，這不是由於模式語言本身的特性造成的。清單 1 是一個示例 RELAX NG 模式（緊湊語法）的片段：

　　清單 1. 使用註釋提供語義線索的 RELAX NG 模式

　　namespace dc = ""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 的屬性，其值是普通文字。這個屬性定義有自己的註釋，指出了該屬性的意義。最後一行是一個評註。注意，該例中使用註釋提供了幫助理解這個模式語義的重要資訊，而用評註傳達附帶的資訊。就是符合該模式的文件。

　　如果清單 1 是 Acme Organization 採用的訂單模式，那麼獨立的 Zenith Organization 也許會採用清單 2 所示的模式。

　　清單 2. 和清單 1 類似的 RELAX NG 模式

　　namespace dc = ""element po{　dc:description [ "Simple purchase order" ]　attribute number {　　dc:description [ "Number for identifying the purchase order" ]　　text　}　#The rest of the schema here}　

　　注意，其中的註釋是類似的，而具體的元素和屬性名卻不同。相應的文件可能是。看過上面兩個模式的人可以從註釋中發現：一個文件中的 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 = ""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 討論論壇和我們分享。

XML 程式設計思想:XML 建模藝術描述(轉)

相關文章