推薦：基于AJAX技術提高搜索引擎排名
描述 嵌入在你的web頁面中的導航元素能夠降低你的搜索引擎評價排名并且降低你的網站的響應性能。本文作者想同你一起探討如何使用AJAX技術來解決這兩個問題。 許多設計良好的web站點都包含大量

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

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

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

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

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

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

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

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

　　神話：XQuery 將代替 XSLT

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

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

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

　　神話：XQuery 將代替 SQL

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

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

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

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

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

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

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

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

　　神話：XQuery 難以學習

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

分享：XML時代我們擁有.Net
盡管不久微軟將再次接受是否被一分為二的裁決，但微軟主席比爾.蓋茨并沒有因此而放棄壟斷網絡市場的野心。 蓋茨現(xiàn)在已經將大部分公司日常管理事務交給微軟CEO巴爾默及其團隊來管理，他所負責