誤解：XQuery 不是產品，僅僅是很多層中的一層
如果需要管理和操縱 XML 數據，XQuery 就是程序庫、應用程序編程或者服務棧所提供的功能規范。但是，底層的 XML 存儲、檢索和索引機制造成了 XQuery 實現的功能、性能和可伸縮性的很大差異。比如，最初曾經嘗試將 XML 數據保存在關系數據庫的 varchar2 字段中，然後簡單地增加一個 XQuery 引擎層，結果查詢性能很差。這就導致了在內容管理、數據持久性、Web 服務和面向服務架構（SOA）、數據倉庫、聯機分析處理（OLAP）、提取/轉換/加載（ETL）、企業應用程序集成（EAI）和供應方管理等方面形成了專門的 XQuery 解決方案。
誤解：XQuery 對於提高面向服務架構（SOA）的性能、控制復雜性沒有多大用處
構建的系統要處理大量 XML 數據時，軟件架構師和開發人員借助 XQuery 解決性能和復雜性問題。考慮下面的情況和相應的 XQuery 解決方案：
早期的研究表明，基於 ebXML 和 UBL 的服務中有效負載的數量和 XML 模式的復雜性呈爆炸性增長，在這裡 XQuery 可以發揮重要作用。
XQuery 在很大程度上增強了 UDDI 解決方案，因為可以更好地管理和控制 UDDI 注冊中心列出的資源。
軟件架構師發現，滯後（soft-moving）數據緩存能夠改善 SOA 的性能。類似的網頁邊緣緩存中，收到很多對相同信息請求的服務可以使用 XQuery 引擎臨時緩存 XML 數據。Xquery 實現一般同時提供 Xquery 腳本能力和數據持久性或者存儲設施。服務將 XQuery 公開為一種服務，並使用底層的 XQuery XML 數據庫臨時緩存 XML 數據。
另外，在供應鏈應用領域，XQuery XML 存儲和檢索有可能對加速整個系統的性能發揮重要作用。設想一下，在供應鏈事務中需要跟蹤每個產品，而且業務關系使用 XML 文檔描述，如果能利用基於 XQuery 的高級存儲和檢索能力會是什麼樣的。
誤解：XQuery 在數據轉換中起不了多大作用
當采用新模式或者現有模式發生變化時，XQuery 可以在數據轉換中發揮很大的作用。對於需要建立供應鏈應用程序的企業而言，成本最大的部分就是轉換不兼容的消息格式。比如，假設買方采用了 RosettaNet 這樣的標准，和原來內部開發的模式完全不同。作為供應商，就需要供應鏈應用程序兼容 RosettaNet 格式，但是又要避免將現有系統轉移到 RosettaNet 的成本和風險。XQuery 可以幫助您遷移到新標准，又不會終止現有的銷售操作。
XQuery 提供了一種方法，可以將現有的模式映射或轉換到 RosettaNet 格式，而不需要編寫大量的新代碼庫。相反，只需要編寫一個 XQuery，將現有的響應數據轉化成 RosettaNet 響應。
誤解：XQuery 和聯機分析處理（OLAP）以及數據倉庫應用程序沒有什麼關系
XQuery 確實為 OLAP 和數據倉庫應用程序提供了必要的鏈接能力。比如，一般企業通常有多個數據倉庫來跟蹤和分析公司數據。這些倉庫就像是雜亂的地下室，需要花費人力、資金和專門技能才能挖掘出業務知識。將一個地下室和另一個聯系起來需要很大的工作量，成本很高。XQuery 提供了一種解決方案，通過在多個數據倉庫之間建立基於查詢的連接來幫助 OLAP。比如，一個數據倉庫保存發送給日用零售店的產品，另一個數據倉庫保存零售店提供的產品支持電話。 XQuery 通過顯示哪些產品造成最多未解決的支持電話，建立了這兩個數據倉庫之間的橋梁。這就證明了 XQuery 在邏輯數據倉庫、分析、提取/轉換/加載（ETL）和企業應用程序集成（EAI）方面的優勢。
神話：XQuery 不能處理大型數據集，永遠趕不上關系數據庫的運行速度
從很多方面，XQuery 標准業界都將 Internet 看作是一個大型的分布式 XML 數據庫。從這種角度出發，這種查詢語言要具備使用戶在一個或多個相關文檔中發現數據的浏覽能力。從數據庫的角度看， XQuery 是大型數據集上的結構化和基於內容的查詢工具，這一數據集就是世界范圍內的 XML 數據庫。從這個角度來說卻是非常大。
XQuery 解決方案的可伸縮性和性能取決於 XQuery 實現的目標。比如，有些 XQuery 實現強調內容管理和集成服務。這類實現最適合於向有限受眾發布 Web 站點和 Web 門戶。以 XML 數據庫功能為中心的 XQuery 實現最適合高效地處理大型數據集。
要了解 XQuery 實現的主要目標，最簡單的辦法是查看其來源。比如，觀察 XQuery 工作組可以看到兩類完全不同的參與者：從 XML 文檔領域轉向 XQuery 的人和將 XML 作為數據的人。面向文檔的成員具有 SGML 背景，強調快速訪問相對較少的 XML 數據。面向數據庫的成員具有層次、關系和 XML 數據庫的背景，認為對開發人員最重要的是索引、文本搜索擴展、事務和兩階段提交、外部索引和 SDK/API。
誤解：XPath 和 XQuery 不是一回事嗎？
實際上，XQuery 建立在 XPath 和 XSLT 的基礎之上。軟件架構師和開發人員使用 XPath 作為一種查詢語言，發現 XML 文檔中的元素並使用 XSLT 將其轉換成 XHtml 或者另一種 XML 格式。比如，開發人員使用 XPath 在 XML 文件中發現病人的牙科記錄，然後使用 XSLT 將病人信息打包成 Html 顯示在浏覽器中。如果數據已經保存為 XML 格式，這種方法很好，但是 XPath 和 XSLT 只能用於 XML 文件。
XPath 是面向選擇的，XSLT 則面向轉換；這兩種技術仍需要一種有效的方式來選擇、連接並將數據轉化成需要的形式。XQuery 能夠滿足應用程序的數據需求：可以訪問多個數據源、選擇信息和連接數據。這種技術同樣適用於非 XML 數據，包括表單、網頁和其他結構松散的數據。
誤解：XQuery 沒有更新機制
XQuery 規范確實沒有包含更新機制。而且在撰寫本文的時候，XQuery 工作組的主 Xquery 規范正處於“Last Call”狀態，沒有工作組成員願意花費時間來更新規范。我希望 XQuery 規范最終將采用 SQL 風格的方法。更新很可能用一組獨立的操作表示，模仿和支持現有的關系數據庫命令。但是，一些實現者和現有的實現提供了一種更加自由的方式來利用 XQuery 組成更新。
必須指出的是，多數 XQuery 實現都提供了自己的更新機制。比如，一種流行的 XQuery 引擎通過擴展提供了對 XML 數據和非 XML 數據的 Create、Read、Update 和 Delete (CRUD) 操作。
神話：XQuery 規范永遠不會成為 RFC
看來似乎如此，但是撰寫本文的時候， XML Query 工作組和 XSL 工作組的 XQuery、XPath 和 XSLT 語言都進入了“Last Call”狀態。而且已經存在了多種成熟的 XQuery 產品。
神話：XQuery 支持基於記號的文本搜索
雖然 XQuery 全文檢索規范確實定義了基於記號（token-based）的文本檢索， XQuery 工作組有意留下了一些方面未作規定。比如， XQuery 沒有提供加載文檔和查看可用文檔列表的標准機制。按照我的看法，不規定每個方面為 XQuery 帶來了一些可塑性。當前的 XQuery 實現關注的焦點不同，底層的數據管理設施也有很大差異。 這種可塑性使 XQuery 不僅適合作為數據庫搜索引擎，還可用於隊列篩選。非常強大。
結束語
總之，XQuery 看來不錯，減少了創建 XML 服務需要編寫的代碼量。更大的 XQuery 系統提供了查詢 XML 文檔的統一方式，包括 XML 選擇、序列化、全文搜索和函數性數據建模。XQuery 規范工作組的工作還將繼續，為使用 XML 的開發人員帶來更多的好處。