XML 程式設計思想: XMLOpen 會議，再評 XML Hacks(轉)

XML 程式設計思想: XMLOpen 會議，再評 XML Hacks(轉)[@more@]

　　專欄作家 Uche Ogbuji 深入思考了 XMLOpen 會議上提出的幾種觀點，最近在英國劍橋召開的這次會議是關於 XML 處理的一次盛會。值得注意的課題包括 XML 規格、 Semantic Web、XML 管道、Web Proper Names 和資料型別。他還從實用的角度對 XML Hacks 一書作了進一步分析，上一期文章中已經詳細地介紹了這部關於技巧和竅門的書籍。

　　XMLOpen 2004 於 9 月 21 至 23 日在英國的劍橋召開。與會的有很多 XML 專家，大部分來自英國，也有來自歐洲、美國、澳大利亞、日本和其他地方的專家。我在致詞中申明瞭本次會議的主題是 XML與開放標準和開放原始碼的交叉。會議展現了大量的勞動結晶和思想成果，本文將討論與我在其他 developerWorks 文章中已經討論過的問題相關的會議內容。

　　本文的後面將對 XML Hacks 一書作最後的評述，完成 本專欄上一期文章 的討論。

　　卡姆河平底船上的 XML

　　龐特（Punt，一種平底船）是在卡姆河（流經劍橋的一條河）上航行的一種簡單的、類似剛朵拉小船（gondola，威尼斯常見的一種平底船），這條河平靜而莊嚴地流經世界上最著名學府的校園。那些坐了三天的船趕來參加 XMLOpen 會議（請參閱 參考資料）的專家學者，聽到大量對 W3C XML Schema (WXS) 和 Web 服務規格的懷疑、對 XPath 2.0 和 XQuery 的譭譽、對 RELAX NG 和 ISO DSDL 的追捧，以及對透過程式語言和框架處理 XML 的鼓吹（在某種程度上不屬於主流）。這些問題匯合在一起，自然而然地把發言者和那些從事前衛的 XML 工具和技術研究的人分離了出來。

　　XML 規格

　　Schematron 的締造者 Rick Jelliffe 在發言的一開始就宣佈，XML 模式和報告語言已經贏得了足夠的投票，將被批准為 ISO 委員會草案標準，作為 ISO Document Schema Definition Languages（DSDL）：“Rule-based validation”（請參閱 參考資料）的第 3 部分。我在最近的 Schematron 實用入門 中介紹了這個重要的準標準。由於 Schematron 的實現越來越多，並且得到了各種語言的認可，Schematron 一直是會議的熱點話題。

　　Jelliffe 的發言實際上是關於嘗試度量 XML 模式複雜性的經驗。基本的想法是：用一個序數字，來評估針對某個詞彙表及其典型應用實現處理任務（如建立 XSLT 轉換）的難度。Jelliffe 的公式是計算元素型別、屬性和各種特殊情況的個數，可以使用 DTD 或者一個或多個例項文件。雖然對度量的細節有不同的意見，比如複雜內容處理中結構化欄位和控制詞彙表的範圍，但其他人已經考慮甚至實現過這種想法。我提到在 Fourthought 公司（我是這家公司的顧問），我們曾經建立了一種輕型的度量方法，只要客戶給出了需要的詞彙表概貌，就可以估計開發 XML 模式（用 RELAX NG）的難度。是否會出現關於 XML 語言複雜性的通用測量，或者按照軟體質量 ISO 標準的道路標準化這種測量，這是值得關注的一個問題。

　　語義 Web 的 URI 方案？

　　本專欄的以前文章，特別是“ Thinking XML： 知識管理的基本 XML 和 RDF 技術，第七部分”中，我討論了與語義 Web 有關的話題，語義 Web 是 W3C 雄心勃勃的下一代 Web 計劃，詳細註明文件的意義和上下文。語義 Web 技術使用 URI 作為涉及到的所有事物的基本識別符號，無論是計算機記錄、客觀物件還是抽象事物。語義 Web 搜尋遇到的一個挑戰是建立可靠標識某個事物的 URI，而非侷限於事物的某個方面。比如，有時候使用語義 Web 語言描述一個人，人們就用他的 Web 主頁作為代表。但這樣做混淆了真正的主頁自身和這個人的描述。

　　開發人員、研究人員、W3C 職員和知名的 XSL 與 Schema 工作組成員 Henry Thompson，提出了使用稱為 Web Proper Names 新 URI 方案解決這一問題。按照 WPN 方案，URI 是以知名引擎（如 Google）的搜尋結果為基礎構造的，URI 包括搜尋引擎的細節和使用的搜尋條件、搜尋的日期和語言、某個人對搜尋結果進行相關性檢查的程度，這個關鍵的人稱為所有者，或者按照 Thompson 的說法叫“施洗者”，是對這個名字負責的人或者實體。施洗者通常和執行搜尋並檢查結果的是同一個人。

　　下面是 WPN 的一個例子。如果要斷言某個人，應該對這個人的姓名執行搜尋，並使用適當的條件限制範圍，得到和這個人關係最密切的結果。因此，如果某個“Ralph Parker”從事材料工程，而另一個從事醫藥行業，若希望描述後者，可以指定搜尋條件忽略出現詞語“材料”的頁面。搜尋引擎可能返回 Ralph Parker 的主頁，您可能也曾經考慮使用它作為表示這個人的 URI。但是如果使用 WPN，就會更加明確所要描述的不是該 Web 頁面（也不是搜尋結果返回的其他任何頁面），而是這些網頁相關的物件。WPN 可能很長，下面是 Thompson 列舉的關於艾菲爾鐵塔的例子：

wpn://~ht/WPN/EiffelTower?terms=eiffel+tower+paris+-hotel+-webcam&ln=en&se=

　　注意：在上面的例子中，程式碼通常作為單獨的連續行出現，但為了便於設定格式和列印，將它分成了多行。

　　我曾經在這次訪談中指出，按照某些支持者的陳述，語義 Web 可能超出了下一代 Web 的能力。資訊科技基於這樣一種認識，所處理的資料僅僅是客觀事物的相似物。我們處理人員、組織、地點、觀念等的計算機記錄，而不是這些事物的客觀存在。名稱、詞語和含義的哲學體系非常古老而且爭議頗多，稍微涉及計算機識別符號在現實世界中的具體 含義這類問題，都會引起無限的複雜性和陷阱。語義 Web 應該專注於為 Web 作者提供廉價、簡單的工具（更具體地說，就是提供開放原始碼的替代品，而且半天就能學會的工具），使其用相關的思想註解頁面。按照興趣組織的社群，形成現約定俗成的慣例，就像人們遇到資訊共享問題時所做的那樣。在封閉的系統中（比如一個組織），約定是透過行政手段強制實施的。（結果，識別符號的含義由組織的政策決定，完全是固定的）。對於語義 Web 來說，強制採用統一的識別符號甚至慣例都是不可能的任務，無論您支援 RDF 還是支援主題對映。

　　最後，Thompson 的想法很有創見，我計劃以不那麼雄心勃勃的方式使用它。比方說，在 Weblog 中定義和描述它的主題似乎是個好主意，特別是因為 WPN 能夠被轉化成 HTTP URL，後者被轉化為 Resource Directory Description Language（RDDL）—— 請參閱我撰寫的文章“ 將 RDDL 用於 XML 和 Web 服務名稱空間”。

　　XML 管道

　　Sean McGrath 長期以來一直鼓吹 XML 管道，他稱之為“將系統看作資料流而非物件 API 的方式”。XML 管道是將 XML 處理專案分解成更小的任務，再分別由獨立的、可重用的處理階段完成這些任務的一種方式。比如，可以透過一個階段重新命名 XML 檔案中的某些元素，另一個階段在根據換行例程在文字中增加新行字元，最後再把文件轉化成文字檔案輸出。管道屬於傳統的 分而治之問題解決方法，基本上所有程式設計師都熟悉它。但不要認為是把演算法分解成可管理的塊，McGrath 和其他管道支持者強調的是資料和資料轉換。他接受了軟體工程先驅 Michael Jackson 的思想，所有要處理的資料都可以分解成關於時間的資料流。McGrath 認為，Web 服務和建立的其他很多 XML 處理實踐都把資料硬套進了目前流行的程式設計技術，帶來了不必要的複雜性。管道恢復了 XML 賴以成功的簡單性和多功能性。

　　McGrath 討論了管道的很多特點，包括相對容易審計和除錯、管道階段重用的價值、每個管道階段可以使用最合適的編輯工具編寫，有人使用 SAX，有人使用 DOM，還有人使用 XSLT。他還談到了在管道資料流之間合併和分解的技術和 delta schemata —— 使用模式計算管道階段之間的中間資料量。管道以多種不同的形式出現在 XML 領域中，包括 ISO 的 DSDL，它使用管道方法將 XML 模式的很多方面分解成更小的、獨立的規範。XML 最佳實踐仍在演化之中，但很多專家同意這種或那種形式的管道是 XML 處理實踐的未來。

　　豐富和可擴充套件的資料型別

　　WXS 資料型別規範（WXS 規範的第 2 部分）常常被其他規範引用，特別是 W3C 規範，但是也飽受批評，被認為是隨意的、複雜的資料型別集合，常常不能滿足實際應用的需求。Jeni Tennison 對這個問題研究了一段時間，並開發了 Data Type Library Language（資料型別庫語言）（DTLL，請參閱 參考資料），作為規定自定義 XML 資料型別的一種方法。她發現實際 XML 資料更多的是供人類閱讀而不是作為處理的表示，從而受到了啟發。這種觀點與 RELAX NG 非常吻合，事實上 DTLL 的主要目標是為 RELAX NG 定義資料型別庫。RELAX NG 是 ISO DSDL 的第三部分，而 DSDL 是“Part 5: Data types”當前的候選方案。

　　DTLL 透過定義正規表示式將資料型別分解成不同的要素（如 RGB 色彩值中的紅、藍、綠），來通知解析器如何解析資料型別。然後可以表達如何對資料型別進行相等測試，或者規定先後順序。這樣就可以方便地在 XSLT 的 xsl:for-each 語句或者其他處理設定中使用。DTLL 支援型別成分的繼承（超型別），以及其他支援資料型別庫模組化和重用的特性。總之，這些特性是經過對現有常用 XML 詞彙表所用資料型別的詳細分析而得到的，包括 DocBook、XHTML、SVG、MathML 等等，我撰寫的“ XML 標準概覽：第 4 部分”中都有介紹。將 XML 這類文字格式繫結到通常使用非文字型資料的很多資料型別和系統涉及到一些非常困難的問題，Tennison 對此進行了深入思考，而且她承認還有一些問題仍然沒有解決。DTLL 仍然很年輕，但是因為其優點再加上 ISO 的支援，您很快就會將其用於與處理需求關係密切的資料型別。

　　關於“ XML Hacks”的一點說明

　　我進一步研讀了 XML Hacks 一書。Hack #92，“Use Elements Instead of Entities to Avoid the 'amp Explosion Problem'”，這一節討論了由於粗心大意造成不必要和模糊文字的問題，如“&”。如果轉義已經轉義的文字就會出現這種情況。該書中給出的解決方法是用特殊的元素表示這類實體，然後在處理結束後再用需要的是替代體元素（大概使用上述的管道）。我懷疑這種措施是否必要。XML 系統知道所處理的每段文字的來源和狀態非常重要。具體地說，系統必須記錄在 XML 表示中文字是否已經轉義。如果不跟蹤這些問題，就可能造成更大的損害，而不僅僅是多餘的實體轉義。如果系統沒有記錄每段文字的來源和狀態，那麼這一節所述的問題就根本不會出現。我不同意書中給出的解決方法，因為這樣補償處理的缺陷增加了處理的複雜性。最好的辦法是修正錯誤。如果使用處理管道，那麼關鍵就是建立管道輸入和輸出的契約，無論資料是否轉義。

　　結束語

　　看到 XML 處理領域不斷成熟非常令人高興，以前幾篇文章中所討論的書籍、剛剛召開的 XMLOpen 會議就是證明。在這段重要時期內開發出專業化的約定和標準，是充分利用 XML 優勢的關鍵，這些優點已經吸引了很多人。我強烈建議您參與到這個過程中來，一種辦法就是在 Thinking XML 討論論壇 中介紹您的想法和經驗。