DIV CSS 佈局教程網

　本期文章將繼續探討語義透明的許多不同方法，介紹這些方法對使用 XML 的開發人員的影響。長途旅行中節省體力的一種辦法是搭便車。在 XML 中，可以利用數不清的開放的模式計劃，其結果就是通過模式標准化實現自從而下的語義透明。但這並非完全免費的搭便車。在本文中，Uche Ogbuji 考察了第三方模式重用的優缺點。他還提到了 The Semantic Technology Conference 2005，對最近關於姓名建模困難性的討論作了答復。

　　從上一期文章“Thinking XML: XML 建模藝術描述”開始，我計劃就這一話題寫三篇文章，恰好完成本專欄的第 30 期。上一期文章概述了語義透明的一些有趣的技術和方法，包括我對最新進展的一些看法。本文是第二篇，將查看采用具有定義明確的語義的現有 XML 格式的優缺點。不過首先要提一下我在三月初參加的一個有趣的會議。

　　The Semantic Technology Conference 2005

　　在得克薩斯州奧斯汀召開的 Knowledge TechnologIEs 2001，是我參加的第一個強調與 XML 相關的語義技術的會議。在那次會議上，我看到這類技術潛力的活力和激情。但出席這次會議的主要是一些研究人員和前沿的商業機構。商業代表很少，這在很大程度上反映了技術采用周期的變化。XML 早期的采用者仍然必須讓商業投資機構相信語義技術的價值，而在這樣做的時候，這些采用者發現，因為語義技術很可能延續 XML 的成功，所以他們很大程度上（並且很奇怪地）面臨著與 Web 服務的競爭。

　　我曾經在本專欄中提到，最近商業機構開始看到了語義技術的重要性，3 月 7-10 日在舊金山召開的 The Semantic Technology Conference 2005 也反映出了這一點。與四年前相同的那些人員和主題又重新出現了，但這一次, 與會者大大增加了，主要是商業投資者增加了。從風險投資者（通常是進入周期中某個階段的信號）、技術經理到企業家，人們不但討論語義技術的潛力，還討論商業機會和預期的投資回報。我對 2001 年會議的活力留下了深刻的印象，但這一次卻是令我震撼。而且這也是我參加過的組織最好的一次會議。

我作了題為“XML Design for Semantic Transparency”（參考資料）的發言，闡述了我在本專欄以及其他 developerWorks 文章中討論過的主題。我一直沒有把目光放在語義 Web 的遠景上，而是關注語義技術的現實應用，以提升 XML 技術的價值。聽眾對我的發言予以熱烈的響應，令我深感榮幸。我仍然認為業界還沒有充分利用 XML 和語義技術結合的強大威力，您也可以投入到這一不斷加強的趨勢中來。建議您對 Semantic Technology Conference 2006 保持關注，我將參加這次會議。

　　搭上語義高速公路的便車

　　XML 出現之後不久，業內組織就開始雄心勃勃地為各種各樣的信息研究基於 XML 的標准。這種強行解決語義透明性問題的方法就是我所說的自上而下的方法。這些小組希望定義整個文檔的格式，以及所有元素、屬性和內容的語義。這種方法常常要依靠已有的行業數據詞典或者其他這類標准，如果有的話。有時候就以 EDI 標准作為起點。

　　重用這類標准可以減少開發語義透明數據格式的工作量。這樣做的好處包括：

• 便於和采用相同格式標准的業務伙伴集成。
• 定義明確的語義，不僅僅是單個數據元素，還包括它們的關系和預期的處理模型。
• 可能減少培訓和招募新人的高昂費用，如果使用眾所周知的格式，那麼勞動力市場中會有更多人熟悉它。
• 減少出現規則問題的機會；如果從事規則控制的行業，可能會發現有關規章要求或強烈建議在內外部信息交換中使用特定的數據格式。

　　當然，也要考慮到以下不利之處：

• 標准化的數據格式不一定非常適合您的特殊要求。標准是利益競爭的妥協。標准常常由委員會制定，每種文化中都有關於通常由委員會設計的粗陋成果的尖刻諷刺。您可能會發現，要適應主流標准框架需要做很多工作。很多標准將可擴展性作為一種逃避的理由，如果不小心，您就會陷入極力避免的語義透明性問題。
• 可能會遇到知識產權障礙。與任何熱門技術一樣，XML 空間中堆積了大量可敬而瑣細的版權和專利權，這些對知名的數據格式和某些處理慣例產生了影響。要考慮法律上的障礙和解決這些障礙所花費的代價。
• 關於競爭性標准的諷刺非常適合於 XML。基本上，在商業利益的每個領域，都有多種競爭性的 XML 標准，您會發現自己處於采用哪一種標准的選擇游戲中。此外，由於沒有足夠多的標准注重應用支持聯合使用競爭標准的語義透明技術，您可能發現自己被鎖定到最初的選擇上。

　　詞匯表的部分采用

　您可以選擇折衷的辦法，采用標准化的詞匯表，同時擴展或者修改它，以滿足自己的需求。如果這樣做，那麼一定要多注意完全自行創建詞匯表時所作的保持語義透明性方面的努力。參考目標格式文檔或者數據詞典中的資料可以省不少力，但是如果有什麼變化的話，則需要更加注意形式化所作修改和擴展的語義。確保與使用相同標准的其他詞匯表相比，不會對互操作性造成損害。

　　對於這類折衷，還可以考慮不那麼常見的一種方法：從選定的語法處理單獨語義的模式系統。借助外部的格式或許就能滿足您的需要（雖然通常需要專門化語義而不是語法），下一篇文章中將討論實現這種方法的工具，如 Schematron 抽象模式和 XML 體系結構表單。

　　姓名的命名

　　現在開始討論本文的第二個主要問題。John Cowan 是 XML 領域最博學的專家之一，最近參與了關於 OpenDocument 文件格式（以前稱為 OpenOffice XML 格式）的討論論壇，本專欄以前的文章中曾經介紹過這種文件格式（請參閱參考資料）。我曾在 developerWorks 中多次提到建模姓名是一個非常困難的問題，John 的建議很好地說明了這個問題有多麼困難。他寫道：

IMHO（我曾經研究這個問題多年），結構化姓名使其適應不同文化（隨著學術研究的國際化，這個問題反復出現）的所有嘗試都失敗了。

• 西歐及其文化後裔將姓放在最後顯示，但是稱呼的時候放在前面。
• 匈牙利人總是將姓放在前面，至少在匈牙利語中如此。
• 中國人也將姓放在前面，而且在其他語言中提到時也常常保留這種習慣。
• 冰島人（多數）沒有姓，只有名和父名，稱呼和顯示都是使用名+父名的形式。
• 印度尼西亞人多數只有一個名。

我認為統一的惟一辦法就是用兩種方法表示全名：一個用於顯示，一個用於稱呼。可以使用下面的標記法：<name><part key='2'>John</part> <part key='1'>Cowan</part></name> 但我認為真的沒有這個必要。 <name sortAs='Cowan, John'>John Cowan</name> 雖然內容有重復，可能更合適。

　　從建模的觀點來看，這是一種合理的辦法，但確實造成了這種難堪的可能性，即必須輸入個人的姓名兩次，從而確保名字不同形式的正確性。事實上，後來在討論中，Cowan 曾提到過如果在這種情況下抄捷徑會有多危險：

將姓名縮寫成[最終表示的]格式需要手工調整，比如中間名“O'Flynn”縮寫為“O'F.”，或者知道“Willard van Orman Quine”是“Quine, W.V.O.”的完整形式。即使自動倒轉姓名也很難：“William Lyon Mackenzie King”倒轉後成為“MackenzIE King, William Lyon”，雖然我們通常稱呼他“King”。

　　同一個論壇中，David Wheeler 提供了一個建議，很好地說明了跨文化建模姓名的重要性：

有一些命名標准，但是真正國際化的標准過於復雜，實際上從未使用過。

　　John 在發給我的一條消息中提到，他曾經遇到這樣的命名問題：“在[國際電子郵件地址和傳輸標准] X.400 和[國際目錄標准] X.500 上下文中，前者提供了完整的頭銜、名、中間名、姓和‘一般稱謂’（即 ‘Sr.’、‘Jr.’或‘III’），後者出現的較晚，只有‘常用名’和‘姓’。前者非常適合顯示，稱呼實際上使用的是後者。”

　　建模姓名是一個老問題，這個問題並沒有隨著技術的逐漸全球化而變得簡單一點。雖然只有少數人會直接面對國際化姓名建模的復雜性問題，但您腦子裡應該對這一問題的困難有所了解，對這種最常見而令人尴尬的建模問題做好心理准備。

　　到底什麼是標准？

　　我一直建議至少要考慮使用外部開發的 XML 詞匯表。自己設計 XML 格式似乎很簡單。但我從實踐中了解到，“設計一種有用的 XML 格式能多麼難呢？”通常是在以後陷入困境的前奏。在尋求語義透明性的過程中，決定是否采用行業標准的重要一步是發現和評估候選標准本身。XML 的流行造成了 XML 標准格式開發的泛濫，因此這個問題也不一定很簡單。在最近的技巧文章（請參閱參考資料）中，我介紹了一些尋找適當的 XML 詞匯表的地方。本專欄中也重點討論了特定行業專用的一些標准，以及一些更通用的標准。請加入 Thinking XML 討論論壇，分享您使用流行 XML 格式的經驗。