XML 程式設計思想: Harold 的高效 XML 設計原則(轉)
知名 XML 專家 Elliotte Rusty Harold 的著作 Effective XML為 XML 技術使用者提供了最佳實踐。該書中關於 XML 設計問題的多數討論 Uche Ogbuji 也曾經關注過,在本文中,他以該書為線索,進一步探討了 XML 設計和最佳實踐。請在本文的 討論論壇上與作者和其他讀者分享您對本文的看法。
我的同事 Elliotte Rusty Harold 是一位知名的 XML 教育家和 XML 軟體開發人員,他以其他方式為 XML 的發展作出了貢獻。我們都對 XML 使用者和開發人員的最簡實踐和清晰思路抱有濃厚的興趣。在最近的 developerWorks文章中,我提供了自己關於這方面的建議和經驗。Harold 則把他自己關於這方面的思考整理成了一本書—— Effective XML。正如該書的主頁上所指出的那樣:
Effective XML是關於使用 XML 的指導原則和最佳實踐的彙總。它關注的是如何使用和開發 XML 應用程式,並特別強調了 XML 的哪些方面經常被誤解和濫用。本文將討論 Harold 的著作,並融入了我自己對 XML 最佳實踐和規則的變化的研究。
預示著成功的開始
甚至在進入該書的第一章之前,就出現了無論如何都不應該忽略的資料。引言中有一節對經常混淆的一些 XML 術語進行了分類。準確地理解和談論 XML 中很多微妙的術語是正確使用這項技術的基礎。Harold 所做的辨析並非學究式的吹毛求疵,他真正理解了 XML 背後核心概念的關鍵。我從“Namespace versus Namespace Name versus Namespace URI”一節學到了重要的一課。我經常隨意地使用這三個術語,非常感激該書中所作的提醒。
第一部分介紹了 XML 語法,文章討論的第一個話題(和書中的其他多數概念一樣)與我在自己的文章中討論的一些話題非常類似,具體到本例,該話題就是我寫的技巧文章“ 堅持使用 XML 宣告”。我非常不同意書中接下來的一章“Mark Up with ASCII if Possible”中的觀點。我一直認為, XML 完全以 Unicode 為基礎是駁斥 ASCII(和單純使用英語)偏見的一個好理由,這種偏見仍將牢牢控制著軟體行業。我認為 XML 正在迫使盲目崇拜純 ASCII 工具的開發人員提供更好的國際化工具。與其為了適應少數沒有趕上時代的工具而重新考慮 ASCII,還不如讓使用者強迫其供應商實現國際化(也許只需透過選擇不同的廠商,求助於市場的推動即可)。Harold 的建議主要針對的是標記(如標籤名)而不是字元資料,他還認為必須將字元資料本地化。在後面的一節,“Write in Unicode”中,他也朝正確的方向邁出了一步,但是我認為他在這方面的建議對英語報有很大的偏見。
Harold 是開發 XML 1.1 的主要反對者之一,他的意見在 XML 社群引起了神秘而有趣的討論。“Stay with XML 1.0”這一節清楚地說明了他對足夠清晰的術語這一問題的看法,我建議所有必須考慮是否支援 XML 1.1 的人讀一下這一節,特別要注意 XML 1.1 的支持者提出的那些相反觀點。對於我而言,我準備只要可能就繼續堅持使用 XML 1.0,但有趣的是,我也注意到,有一個問題也許會迫使我轉向 XML 1.1:對於可用於 XML 標記結構的字元,它放寬了很多不必要的限制。因為 Harold 更願意堅持在標記中使用 ASCII,這樣的話不理睬 XML 1.1 當然更容易,不過我已經表明不贊同避免使用非 ASCII 標記。
我發現很多和 XML 有關的 1.0 技術在技術上都很卓越,通常因為它們是由才華橫溢的個人或者小組來推動的。不幸的是,1.0 規範的成功帶來無數形形色色對 1.1 或者 2.0 版開發過程的關注,結果, XML 技術開發成了由政治操控並由委員會設計的一個大雜燴。我對 XML 開發人員也有類似的建議,即 堅持使用 XPath 1.0 和 XSLT 1.0 (必要的話結合使用 EXSLT) 。 XPath 和 XSLT 2.0 就是第二代 XML 技術水準降低的典型例子。
我和我大學時代研究作業系統設計實現的同學爭論最激烈的一點是,在命名計算機符號時“首字母大寫”(比如“OneTwo”)是否比下劃線(如“one_two”) 好。當時我堅持首字母大寫更好,但我逐漸認識到他是正確的。使用下劃線在很大程度上改善了可讀性。XML 允許在變數名中使用破折號,因此可以具有下劃線那樣的可讀性,同時輸入起來也更簡單(“one-two”)。(關於這方面的建議位於我的另一篇文章“Keep your XML clean”中,請參閱 參考資料)。Harold 在“Name Elements with Camel Case”一節中推薦了我最不喜歡的選擇。
我認為“White Space Matters”是需要重點閱讀的另一小節。與所有技術語言的開發人員都應該瞭解的其餘小節的內容類似,第一部分的其他內容包括關於 DTD 設計模式的審慎建議。
XML 體系結構
下一部分討論 XML 體系結構問題,前兩節“Make Structure Explicit through Markup”和“Store Metadata in Attributes”探討了很多和我在“ 何時使用元素,何時使用屬性”一文中提出的相同原則和話題。這些章節中的多數討論和我文章中的觀點是互補的。如您所料,在某些方面我有不同的看法,比如 Harold 認為堅決不能將計量單位和數字單獨標記。對於捲入 XML 的每個人,“Remember Mixed Content”和“Allow All XML Syntax”章節也需要重點閱讀。這些章節講述了在 XML 處理中有時候很容易忽略的一些方面,而這些方面會影響 XML 的強大功能。“Use Processing Instructions for Process-Specific Content”這一節讀起來非常有趣,但可能會在 XML 社群中引發爭議,一些人傾向於從 XML 中去掉處理指令。我同意 Harold 的觀點,處理指令可能非常有用。
“Use Namespaces for Modularity and Extensibility”和“Rely on Namespace URIs, Not Prefixes”這兩節反映了我在“ 小心使用 XML 名稱空間”和技巧“ 名稱空間和版本控制”中提出的觀點(也可以在書中“Version Documents, Schemas, and Stylesheets”一節找到)。在下一節“Don't Use Namespace Prefixes in Element Content and Attribute Values”中,我們將更進一步,談論 XML 中引發爭議的另一個問題:XSLT 和其他使用 XPath 的語言在屬性值中使用名稱空間字首,這種方法毫無疑問存在陷阱。但我還沒有看到更高明的方法,除非重新搭建 XML 名稱空間的體系結構(目前來看,這可能是一種不太現實的選擇)。此外,RELAX NG 和 W3C XML Schema (WXS) 在屬性中使用名稱空間字首方面存在很大差異,Harold 暗示不能將這種方法用於 RELAX NG。清單 1 是本書中使用的示例:
清單 1. 不在屬性中使用名稱空間字首編寫的 RELAX NG
清單 2 是 清單 1的改寫形式,它表明 RELAX NG 實際上並沒有禁止在屬性中使用名稱空間字首。
清單 2. 清單 1 的改寫形式
清單 2所用的方法確實需要在屬性中繫結字首。當然如果使用等價的 WXS,就沒法再進行選擇,只能在屬性中使用字首。RELAX NG 的好處在於它 允許避免在屬性中使用名稱空間字首。因此 Harold 的觀點仍然是完全合理的,不過我要澄清的是,事情比他所說的要更復雜一點。
我發現“Reuse XHTML for Generic Narrative Content”這一節非常具有限制性。XML 允許使用各種不同的詞彙表,這一點非常棒,我看不出有什麼理由要對選擇什麼樣的散文體詞彙表進行限制。比如說,Docbook 和 TEI 在語法上都要比 XHTML 更豐富一些,在應用上也是如此。對於一般的記述性的內容,我也習慣使用 XHTML,但是我同樣喜歡有其他的選擇。另外一個原因和我對英語偏見的關注有關:XHTML 標籤通常只對說英語的人具有直觀含義。我建議為說其他語言的使用者開發 XML 詞彙表的人根據這些語言起草一份詞彙表,使 XML 更便於使用者使用。強大的 XSLT 和現成可用的 XML 轉換工具確實是一個奇蹟,沒有人因為了完成某項任務而必須使用特定的 XML 語言。當然, 這裡也應該禁止使用以迷人而最為著稱的 XML 詞彙表——John Cowan 的“Itsy Bitsy Teeny Weeny Simple Hypertext DTD” (IBTWSH DTD),不過在正式的場合,我從來不使用這個 DTD,因為它堅持要求大寫所有的元素型別名。
Harold 和我經常大肆宣揚人們應該把重點放在 XML 是一種文字上,而不要過分關注資料型別化、強資料繫結或者其他諸如 XML 是某種新一輪 DBMS 替代品這類的宣傳。“Pretend There's No Such Thing as the PSVI”一節對大量過編譯(over-compication)XML 的基礎裝置進行了討論:Post Schema Validation Infoset (PSVI)。這是一個用於 XML 文件的型別註釋系統,諸如 WXS、XPath 2.0、XSLT 2.0 和 XQuery 的一些規範中會用到該 XML 文件,並且會將該文件用作基本的 XML 模型,而不是用作真正的 XML 文字。我希望這一節的內容能夠再充實一些,提供更多的例子來完善這種觀點。事實上,這個觀點如此重要,我本來希望能夠在“Treat the Raw Text of XML as Paramount in Processing”在看到一節。
結束語
本書的其他部分討論了與程式設計和處理有關的技巧和觀點,特別強調了 Java 工具和慣用法。這裡不再對它們進行討論,因為現在我關注的是核心 XML 實踐和設計。 Essential XML是一部驚人的鉅著,我強烈推薦這本書。但我並不同意書中的所有觀點,如果我同意那樣一部書中的每一個觀點,那麼我一定是瘋了。Harold 明確列舉了一些基本原則,只要認真地考慮考慮,任何讀者都會成為 XML 的更好的使用者。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752019/viewspace-950165/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- XML 程式設計思想:XML語義(轉)XML程式設計
- XML 程式設計思想:XML和語義(轉)XML程式設計
- XML 程式設計思想: 研讀XML Hacks(轉)XML程式設計
- XML 程式設計思想: XML 語義錨(轉)XML程式設計
- XML 程式設計思想:XML 建模藝術描述(轉)XML程式設計
- XML 程式設計思想:查詢 XML 格式的 WordNet(轉)XML程式設計
- XML 程式設計思想: 專利編檔遭遇 XML(轉)XML程式設計
- XML 程式設計思想: XMLOpen 會議,再評 XML Hacks(轉)XML程式設計
- XML 程式設計思想:XML和語義:XML 會兌現其承諾嗎?(轉)XML程式設計
- XML 程式設計思想:從書本學習 XML Topic Maps(轉)XML程式設計
- XML 程式設計思想:Thinking XML: 通用商業語言(UBL)(轉)XML程式設計Thinking
- XML 程式設計思想:使用 XSLT 生成 RDF(轉)XML程式設計
- XML 程式設計思想: 學習物件後設資料(轉)XML程式設計物件
- XML 程式設計思想:重新審視 XML 中的語義透明性(轉)XML程式設計
- XML 程式設計思想:知識管理的基本 XML 和 RDF 技術(7)(轉)XML程式設計
- XML 程式設計思想:踏著語義的節拍(轉)XML程式設計
- XML 程式設計思想:用 MusicBrainz 管理後設資料(轉)XML程式設計AI
- XML 程式設計思想:知識管理的基本 XML 和 RDF 技術:語義知識(轉)XML程式設計
- XML 程式設計思想: UBL 1.0(以及 ebXML Core Components 等)(轉)XML程式設計
- XML 程式設計思想:知識管理的基本 XML 和 RDF 技術:問題跟蹤程式模式(轉)XML程式設計模式
- XML程式設計例項(二) (轉)XML程式設計
- XML與ASP程式設計(一) (轉)XML程式設計
- XML 程式設計思想:定義 RDF 和 DAML+OIL 圖示(轉)XML程式設計
- shell vbscript xml程式設計XML程式設計
- XML 程式設計思想:利用模式標準化實現自上而下的語義透明(轉)XML程式設計模式
- XML 程式設計思想: 使用 Atom 格式連鎖新聞及其他內容(轉)XML程式設計
- 使XML程式設計更簡單---JDOM介紹及程式設計指南 (轉)XML程式設計
- 程式設計原則程式設計
- Java XML程式設計例項解析JavaXML程式設計
- XML 程式設計思想:將檔案合併到 RDF 模型和基本的 RDF 查詢(轉)XML程式設計模型
- 探究平臺化設計的核心思想和Lattice的設計原則
- 程式設計原則(整理)程式設計
- 設計模式的設計原則設計模式
- 程式設計師應該遵守的程式設計原則程式設計師
- 設計原則-依賴反轉原則
- 【設計原則】物件導向程式設計的六大原則物件程式設計
- Python學習筆記之 Python設計思想&設計原則Python筆記
- 設計原則 設計模式設計模式