揭穿 XQuery 的神話和誤解

2024-09-05 20:54:03

字體：大中小

來源：轉載

供稿：網(wǎng)友

　XQuery 給軟件架構師和開發(fā)人員帶來了很多希望，因為大大減少了建立使用 XML 的服務所需要編寫的代碼量。您也許認為 XQuery 所做的一切很容易理解，但是在 XQuery 的軟件開發(fā)社區(qū)中仍然存在著錯誤的想法和誤解。Frank Cohen 在本文中詳細剖析和澄清了圍繞著 XQuery 的很多神秘色彩和誤解。

　　如果您在使用 XML、Web 或者面向服務的架構（Service Oriented Architecture，SOA），那么很可能會從 XML Query (XQuery) 標準的制定中受益。雖然 XQuery 還未批準為正式標準，但已經(jīng)有幾十種實現(xiàn)每天都在幫助軟件架構師和開發(fā)人員了。即將形成的 XML 文檔查詢標準包括了下一代 XML 選擇語言（XPath 2）、XML 序列化、全文檢索和功能性 XML 數(shù)據(jù)建模。這樣規(guī)模的項目免不了有很多神話和誤解需要揭穿。下面是圍繞著 XQuery 的一些常見的神話和誤解。

　　誤解：數(shù)據(jù)庫公司將 XQuery 視作其核心業(yè)務的直接對手

　　數(shù)據(jù)庫公司將 XQuery 看作一個機會，與其核心解決方案互相補充。

　　對于軟件架構師和開發(fā)人員而言，XQuery 提高了生產(chǎn)率，增加了敏捷性。工具供應商迫切希望支持 XQuery 是合情合理的。

　　對于開發(fā)人員來說，XQuery 很像 SQL，自然而然地對兩者加以比較。何況越來越多的數(shù)據(jù)正使用 XML 標記，這就迫使數(shù)據(jù)庫公司在產(chǎn)品中增加 XML 存儲、持久性和查詢的能力。XQuery 擁有如此眾多的開發(fā)人員支持，以至于 IBM 和 Oracle 將它們的角逐放在一旁，轉而擴展其核心數(shù)據(jù)庫產(chǎn)品以提供 XQuery 能力。

　　數(shù)據(jù)庫公司也看到了成為第一個充分利用 XML 格式的數(shù)據(jù)庫供應商（從而最終成為市場霸主）所帶來的機會。目前存儲在關系數(shù)據(jù)庫中的數(shù)據(jù)按照行和字段進行了規(guī)格化。在 XML 世界中，每一行包含無限多個字段，每個字段都是父/子層次結構中的一部分。最先提供高性能和 XQuery 靈活性的供應商將贏得一個巨大的新市場。

　　一個證據(jù)是，XQuery 將 IBM 和 Oracle 團結在一起（不再是兇狠的對手），合作提出 JSR 225（參閱參考資料）， XQuery API for Java (XQJ)。在 .NET 這一邊，Microsoft 和 IBM 共同向萬維網(wǎng)聯(lián)盟（W3C）提交了 XQuery 測試包。

　　神話：XQuery 將代替 XSLT

　　XQuery 和 XSLT 都有足夠多的開發(fā)人員支持，將共存下去。事實上，XQuery 1.0 和 XSLT 2.0 最新規(guī)范的開發(fā)是先后進行的。

　　XQuery 和 XSLT 交叉之處在于它們解決的問題：XML 數(shù)據(jù)轉換、XML 集合聯(lián)邦和 XML 數(shù)據(jù)高級查詢。開發(fā)人員仍仍將看到關于這兩種技術的爭論，包括各種各樣的神話和誤解。比如，我常常聽說 XQuery 能夠一次查詢多個不同的源文件，因此要比 XSLT 優(yōu)越得多。事實上，XSLT 2.0 處理程序允許在輸入隊列中給出多個節(jié)點。 XSLT 1.0 有 document() 函數(shù)，可以在一次轉換中訪問多個源文件，XSLT 2.0 還支持新的 collection() 函數(shù)。我也常常聽到這樣的說法，雖然 XQuery 的語法看起來更好，但是缺少 XSLT 模板風格的模式匹配。雖然這也許是真的，但我堅信 XQuery 也會增加這一功能。最終，開發(fā)人員可以預期這兩種技術的改進和競爭將使它們的功能和能力不相上下。

　　最后，還有開發(fā)人員頭腦遲鈍的問題。參加的那些 XSLT 會議讓我感到，我并沒有真正理解它。 XSLT 的轉換語法并沒有像 Java 和 Jython 中通常所用的 main() 或 start 方法。我有時候將 XSLT 看作一種腳本，說明并沒有真正理解 XSLT。XQuery 看起來很像 SQL，解決了很多我不得不從書架上翻找答案的問題。

　　神話：XQuery 將代替 SQL

　　XQuery 最適合于 XML，就像 SQL 最適合于關系數(shù)據(jù)。 XQuery 為需要訪問、挑選、集成和轉換一個或多個 XML 集合的應用程序提供了類似于 SQL 的查詢能力。雖然 XML 的狂熱者可能將世界上的一切都看成是用 XML 標簽編碼的，單關系數(shù)據(jù)庫模型仍然根深蒂固，世界上大部分數(shù)字數(shù)據(jù)是用由行和列組成的表來進行編碼的。SQL 不會很快地消失。相反已經(jīng)出現(xiàn) XQuery 擴展，將 SQL 調用的結果看作是 XML 文檔集合的一部分。

　　如上所述，XQuery 對于 XML 就像 SQL 對于關系數(shù)據(jù)庫。但是，有些時候甚至相對于關系數(shù)據(jù)庫而言，XQuery 更容易使用。比方說，對于一般開發(fā)人員，使用 SQL 創(chuàng)建輸出結果為新 XML 文檔的多表外連接查詢要比編寫 XQuery 復雜得多。

　　XML 的普及已經(jīng)迫使標準團體工作組擴展 SQL 規(guī)范，以便納入 XML 處理功能。 SQLX Group、INCITS H2 小組和 ISO/IEC JTC1/SC32/WG2 的 SQL/XML 標準化都在致力于擴展 SQL 標準，使其能夠處理 XML 數(shù)據(jù)。

　　誤解：采用 XQuery 必須放棄過程性編程而轉向面向對象編程

　　對于 XQuery 來說，過程性腳本語言和面向對象的編程語言都是一樣的。如果愿意編寫 PHP腳本，仍然可以繼續(xù)這樣做。多數(shù)現(xiàn)有的編程語言都有 XQuery 實現(xiàn)。

　　XQuery 給開發(fā)人員帶來的好處是減少了執(zhí)行查詢所需要的代碼量。有時候關系數(shù)據(jù)在兩個或更多的數(shù)據(jù)庫中，開發(fā)人員需要生成報表來顯示兩個數(shù)據(jù)庫的并。喜歡使用 Python 這類過程性編程語言的開發(fā)人員可能要編寫 100 或更多代碼行來檢索、解析和處理數(shù)據(jù)。當然也可以編寫幾行 XQuery 來完成。

　　神話：XQuery 比 JDOM、JAXP 和其他 XML 解析 API 更難用

　　XQuery 用于 XML 數(shù)據(jù)并不比 XML 解析 API 更難。JDOM、JAXP 以及其他 XML 解析 API 提供了處理 XML 數(shù)據(jù)的 Java 代碼和方法。很多面向對象的設計模式都準備編寫處理 XML 文檔復雜性的對象。編寫 Java 對象需要時間、精力和專門的技能。底層 XML 數(shù)據(jù)格式的任何細微變化都需要修改對象。XQuery 的擁護者可以肯定地說，和使用 JDOM 編寫 Java 對象相比，XQuery 腳本能夠更快地發(fā)現(xiàn)應用程序需要表示的 XML 數(shù)據(jù)。另外，很多 XQuery 庫都提供了 Java 接口，因此可以在 Java 類中編寫 XQuery 代碼來獲得結果集，就像調用一個方法一樣。然后讓 Java 類處理結果。

　　神話：XQuery 難以學習

　　使用 Java、.NET 和其他語言的軟件開發(fā)人員發(fā)現(xiàn) XQuery 很容易學。XML 有很多不那么優(yōu)美的地方，包括從早期的 SGML 標準繼承下來的那些部分。 XQuery 使用一組簡潔的命令，很容易處理 XML。雖然一般開人員要掌握 XQuery 面臨著一些困難，但是學習曲線并不很陡峭，也不長。

上一篇：XML的四種解析器原理及性能比較

下一篇：使用XSL將XML文檔中的CDATA注釋輸出為HTML文本