級別: 初級
Howard Katz, 所有者, Fatdog Software
2001 年 6 月 01 日
2006 年 2 月 06 日 更新
Howard
Katz 介紹了 W3C XQuery 規范，該規范目前正在努力成為推薦標準。這個復雜的規范目前包含 15
個不同的工作草案，而且在最終完成之前可能還會增加。本文提供了該規范的一些歷史背景、形成文檔的路線圖和規范當前狀態的簡單介紹。側欄簡要描述了
XQuery 表層語法的一些主要特性。通過示例代碼示范了 XQuery 和 XQueryX 之間的區別，并給出了關于表層語法的例子。
注意：本文在
2005 年 12 月經過修正，結合了 XQuery 規范的最新變動情況：其中八個工作草案已進入 “W3C 候選推薦標準”
狀態，整個規范距離最終成為 “推薦標準” 更近了一步。主要的全文文檔最初發表于 2004 年，最近經過了修改。關于更新設施的
“需求工作草案（Requirements Working Draft）” 和建立 XPath/XQuery
詞法分析器（tokenizer）的草案都是 2005 年第一次發布的。XQuery 特性的數量繼續增長，XQuery 實現者列表和 Web
上的開發人員資源也在不斷增加。
沿著成為 W3C 推薦標準的道路走了漫長的六年之后，XQuery
規范頗具好萊塢大片的神秘和不朽色彩，就像 “星球大戰” 和 “指環王” 系列一樣。XQuery 起源于 1998 年由 W3C
發起的查詢語言研討會，來自工業界、學術界和研究團體的代表聚集到波士頓，提出了 XML 查詢語言中他們認為重要的特性和需求。
兩個不同的陣營
那些對歷史感興趣的人可以在線獲取這 66 篇演講稿（參閱 參考資料），它們主要來自兩大不同的陣營：那些將 XML 主要作為文檔 使用的人（在很大程度上反映了 XML 起源于 SGML）和將 XML 作為數據 使用的人 —— 后者很大程度上反映了 XML 在中間件領域、前端傳統關系數據庫領域中不斷增長的現狀。
尤
其是俄勒岡州研究生院的 David Maier的演講稿 “Database Desiderata for an XML Query
Language”，它非常簡明扼要，非常有助于了解 Query Language Working
Group（查詢語言工作組）的思想，后者是在波士頓討論會之后不久特許成立的。
雖然成員時增時減，但按照 W3C
的標準，這個工作組很龐大（據說只有 Protocol Working Group（協議工作組）的成員比它多）。它由 30
多個成員公司構成，反映了數據和文檔這兩大陣營各自的觀點。現在合并而成的最終形式（經過了漫長的時間）是一種 XML 查詢語言標準，
能夠代表這兩個團體的需求和觀點。
對于 XML 用戶來說，最熟悉的 XQuery 關鍵組件是
XPath，它本身也是一個 W3C 規范。單獨的 XPath 位置路徑本身（“//book/editor” 意味著
“在當前數據集中查找所有圖書編輯”）就是完全有效的 XQuery。在數據方面，XQuery 具有類似于 SQL
的外觀和能力，這是來自關系數據庫世界的用戶所歡迎和熟悉的。
卑微的出身
XQuery
最初稱為 Quilt。Quilt 最初作為用戶級語法的測試工具，是工作組中三個勤奮而又眼光遠大的成員創立的：Jonathan
Robie、Don Chamberlin 和 Daniela Florescu。在定義需求、用例以及底層數據模型和代數方面，Quilt
都建立在整個工作組的協同努力的基礎上。
Robie、Chamberlin 和 Florescu 指出了一些語言對
Quilt 設計的影響，包括 XQL、XML-QL 和 SQL。如果對計算機語言的演化感興趣，請閱讀 “XML Query Language:
Experiences and Exemplars”（參閱 參考資料），這篇意義重大的論文對前兩種語言以及另外兩種語言 YaTL 和 Lorel 進行了很好的比較。作者 Mary Fernandez、Jerome Simeon 和 Phil Wadler 本身都是該工作組的成員。
既然數據和文檔團體持有如此不同的的觀點，以及工作組所建立的基礎的可靠性，這個龐大的規范需要如此長的時間才向大眾公布也就不足為奇了。W3C 工作組的內部進展是嚴格保密的，并且在 2001 年 2 月中旬以前，查詢語言工作組的大多數工作都是秘密進行的。
很
早就發布了 Requirements 文檔和 Data Model 工作草案，但是直到 2001 年 2
月，工作組的發布工作才得以進入高潮，那時大量的文檔開始出現。此后在 2001 年進行了兩次重要更新，以后每年都有三四次更新，只有 2004
年例外，工作組只發布了一次更新。
今年新增加了更新機制的需求文檔，再加上為 XQuery
語言實現者提供的關于建立詞法分析器的簡短說明，文檔總數達到了 16 個（包括由于某種我不清楚的原因也放在 XML Query 網站上的
XSLT 規范），不用很長時間就會組成一套完整的文檔集。肯定會在某個時候出現一種更新語言文檔。
新生的發布王國
完全用于描述和定義 XQuery 的文檔目前包括：
-
XML Query Requirements
- 工作組的主要規劃文檔。XQuery 需求列表。
-
XML Query Use Cases
- 一些實際場景和解決特定問題的 XQuery 片段。
-
XQuery 1.0: An XML Query Language
- 核心文檔，介紹語言本身，以及對大多數其他內容的概述。
-
XQuery 1.0 and XPath 2.0 Data Model
- XML 信息集的擴展。描述查詢實現必須理解的數據項和形式語義的基礎。
-
XQuery 1.0 and XPath 2.0 Formal Semantics
- 從形式上定義語言的底層代數。
-
XML Syntax for XQuery 1.0 (XQueryX)
- 為喜歡使用 XML 的人（主要是計算機）提供的另一種語法。
-
XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0
- XML Schema 數據類型、 XML 節點及其序列的大約 225 個函數和操作符。
-
XML Path Language (XPath) 2.0
- 單獨分離出來的 XPath 文檔。
-
XPath Requirements Version 2.0
- XPath 的需求文檔。
-
XSLT 2.0 and XQuery 1.0 Serialization
- 對從 XQuery 1.0 和 XPath 2.0 Data Model 輸出序列化尖括號 有關的 XML 問題的考察。序列化本質上 不是主語言規范的一部分。
-
XML Query and XPath Full-Text Requirements
- 描述 Full-Text Recommendation 需要達到的功能需求。
-
XML Query and XPath Full-Text Use Cases
- Full-Text 規范應該能夠處理的實際場景。
-
XQuery 1.0 and XPath 2.0 Full-Text
- 主 full-text 文檔，詳細描述嚴格意義上的 XQuery 的全文擴展語言。
-
XQuery Update Facility Requirements
- XQuery 要求的能夠對已有文檔寫入新數據以及對文檔進行查詢的功能。
-
Building a Tokenizer for XPath or XQuery
- 工作草案注釋文件，選擇了主 XQuery 1.0 文檔中的一些語法資料進行解釋。只對語言的實現者有意義。
這些文檔（參閱 參考資料）
代表了大量工作。“XQuery 1.0: An XML Query Language” 是其中的關鍵，但其他文檔也為 XQuery
成為良好的規范和全面支持的語言作出了貢獻。據我所知，這是出自 W3C 的最復雜的一套規范（雖然 XML Schema
或許可與之相比，但那又是另一回事了）。
如果您對如此之多的文檔感到驚訝和不知道從何處著手，我可以推薦兩種方法。可以從核心的 XQuery 1.0
文檔開始。它有一個很好的介紹性概述，詳細介紹了該語言的很多特性。另一種方法是從選擇一個 Use Cases 工作草案開始。該文檔列舉了
XQuery 能夠發揮作用的一些實際場景。每個用例都針對特定的應用領域，并列出了用于該領域示例數據的一些 XQuery
代碼。如果希望看到實際語法的具體例子，這些代碼片段是非常有價值的。第三種方法是研究 Functions and Operators
工作草案中列出的很多內置函數，但采用這種方法最好對語言要有基本的理解。
最近幾年關于這個領域出現了兩本很好的圖書，闡釋
了該規范的各種細節，都是 Addison-Wesley 出版的：“XQuery from the Experts”
收集了來自該工作組成員的一些關于 XQuery 的技術文章，而 “XQuery: The XML Query Language” 則是
Microsoft 的 Michael Brundage 撰寫的必讀參考書（參閱 參考資料）。
BabelFish，您在哪兒？
XQuery 實際上是三種語言合為一體：
-
表層語法是其中最容易看到的語言，也是用戶最可能接觸到的。從很多方面來說，這個語言版本就是 XQuery。（參閱側欄 語法：一個簡單的例子 中關于表層語法的例子。）
-
一種基于 XML 的替代語法用另一種更便于機器處理的語言代替了表層語言。（參閱本文后面的 XQueryX。）
-
形式代數語言詳細描述了 XQuery 處理程序的內部工作機制。
底層的形式主義
Data Model and Formal Semantics（數據模型和形式語義）工作草案共同為 XQuery 提供了精確的理論基礎。這兩個文檔詳細介紹了查詢代數，這是用形式術語定義的一組精確定義，它定義了 XQuery 查詢期望操作的核心實體以及各種語言操作符怎樣使用那些操作數的公式。除非是查詢引擎的實現者、有充足的經費保障或者單純喜歡復雜的形式系統，否則不會對它感興趣。
提供了一個讓實現者能夠將表面語法特性直接重新造型為底層代數的映射。正如一些廠商在 XML 商業展示會上所展示的那樣，可以實現實際上與代數直接溝通的查詢處理程序（雖然我認為這更多的是概念證明性的）。參考資料 中有一個鏈接指向其中一個基于代數的引擎的在線演示版本。
代數還提供了詳細描述如何將復雜表達式優化及轉變成更簡單的等價形式的規則。我只能說（我不是語言學家，并且形式語義文檔讀起來并不輕松），它們都是好東西。特別是大型數據庫供應商會贊賞一種從頭開始設計并且經過優化而高效的查詢語言結構。
代數還提供了附加類型信息的位置。XQuery 是強類型的：如果數據有相關的 XML Schema，處理程序就可以按照模式進行驗證、并為查詢引擎提供文檔中節點數據類型的后模式驗證信息集（PSVI）信
息，同時利用 “XML Schema Part 2: Datatypes”
中聲明的類型和自定義的用戶定義類型。代數同時具有靜態和動態類型檢查能力。比方說，引擎可以使用 PSVI
派生的類型信息在編譯時靜態地檢查查詢表達式的數據類型（分析查詢的語法正確性時）。在這個周期中盡早地確定類型無效的查詢，這樣能夠大大減少對大型數據
集進行很可能是昂貴的（和無結果的）搜索的需要。XQuery 規范中涉及到語言的語法和語義的大部分工作都與類型有關。
遷移到 XPath 2.0
XQuery
和 XPath 2.0 具有同樣的公共數據模型，有點奇怪的數據模型文檔標題也反映了這一點：“XQuery 1.0 and XPath 2.0
Data Model”（這也是工作組開始使用縮寫詞 XDM 表示數據模型的原因）。XPath 2.0 現在已經完全成熟。該數據模型描述了
XPath 處理程序所關心的 XML 文檔中的核心信息，XPath step 操作的最終語法和語義基本上已經完成。全部規范為 Query
Language 工作組和 XSL 工作組共同所有，這兩個工作組需要對 XPath 2.0
的未來達成一致。不論在政治上還是在技術上，這常常會帶來挑戰。不過，即便取得一致意見的道路崎嶇不平，這兩個工作組看來并沒有表現出有多么不協調（至少
在外人眼里如此）。
為了說明從 XPath 1.0 轉移到 2.0 的意義，僅僅舉一個例子：XPath 1.0
是基于集合的表達式語言。XPath 1.0 的 4
種數據類型之一，節點集，僅僅是集合而已。按照定義，集合是無序的并且不含重復成員。另一方面，XPath 2.0
卻是以序列為基礎的。相比而言，XPath 2.0 中節點的序列（毫不奇怪，相應地被稱為節點序列）是有序的，并且允許重復。用行話來說，這些差異的分歧存在于許多問題中，工作組需要獨立和協作找出這些問題來，以便使他們都能夠與 XPath 2.0 協調一致。
我們現在在何處？
所有實質性的遺留問題都已經解決。組成 XQuery 的七個關鍵文檔按 W3C 的說法成為了 “候選推薦標準”，這意味著，用正式的術語來說，XQuery 現在被認為 “是穩定的且合適于實現”。
按
照正式的 W3C 推薦標準工作流程，以上 Last Call 階段中提出的所有問題都已得到響應，工作組現在正尋找工業廠商去實際驗證
XQuery
的主要特性是可實現的。為此，實現者必須對工作組提供的測試套件運行其實現。那些在候選推薦標準階段沒有被兩個或更多廠商實現的特性，就有可能被從規范中
刪除。當前有風險的特性包括：
- 靜態類型化
- 模塊
- 集合
- 靜態類型化
- 普通的 XML 嵌入
- 復制名稱空間（Copy-namespace）聲明
XQueryX
XQueryX 是一種替代表層語言的基于 XML 語法的規范，也是較早加入 XQuery 文檔家族的文件之一。XQuery 需求中有一條指出多種語法是允許的，看來工作組似乎是在兩面下注：一種格式必須方便人類讀寫，另一種則要求能夠用 XML 表達。XQueryX 是工作組對后一種需求的答案。
基于 XML 的查詢表是具備 XML 所有顯而易見、眾所周知的優點：很容易使用標準工具解析、生成和詢問查詢的內容。這樣做可能很有用，比方說，如果正在進行源代碼級的優化或轉換，就可能需要方便地檢查查詢中是否具有特定語法結構的能力。XML 非常適合這類工作。
XQueryX 基本上是該語言的形式語法到 XML 的一對一映射。由于語法的復雜性，使得 XQueryX 非常 冗長，基本上無法閱讀。所幸的是，該語言的目標受眾 —— 機器 —— 不會對此抱怨。清單 1 和 2 提供了分別用標準 XQuery 語法和 XQueryX 語法表示的簡單查詢表達式。要注意像類固醇一樣的膨脹因子。
清單 1. 標準語法表示的簡單查詢
<bib>
{
for $b in doc("http://bstore1.example.com/bib.xml")/bib/book
where $b/publisher = "Addison-Wesley" and $b/@year > 1991
return
<book year="{ $b/@year }">
{ $b/title }
</book>
}
</bib>
|
清單 2 顯示了等價的 XQueryX 查詢。因為太長，省略了大約四分之三的篇幅。XQueryX 工作草案中的完整清單有 132 行之多：
清單 2. XQueryX 格式的查詢（片段）
<?xml version="1.0"?>
<xqx:module xmlns:xqx="http://www.w3.org/2005/XQueryX" ... >
<xqx:mainModule>
<xqx:queryBody>
<xqx:elementConstructor>
<xqx:tagName>bib</xqx:tagName>
<xqx:elementContent>
<xqx:flworExpr>
<xqx:forClause>
<xqx:forClauseItem>
<xqx:typedVariableBinding>
<xqx:varName>b</xqx:varName>
</xqx:typedVariableBinding>
<xqx:forExpr>
<xqx:pathExpr>
<xqx:argExpr>
<xqx:functionCallExpr>
<xqx:functionName>doc</xqx:functionName>
<xqx:arguments>
<xqx:stringConstantExpr>
<xqx:value>http://bstore1.example.com/bib.xml</xqx:value>
</xqx:stringConstantExpr>
</xqx:arguments>
</xqx:functionCallExpr>
</xqx:argExpr>
<xqx:stepExpr>
<xqx:xpathAxis>child</xqx:xpathAxis>
<xqx:nameTest>bib</xqx:nameTest>
</xqx:stepExpr>
<xqx:stepExpr>
<xqx:xpathAxis>child</xqx:xpathAxis>
<xqx:nameTest>book</xqx:nameTest>
</xqx:stepExpr>
</xqx:pathExpr>
</xqx:forExpr>
</xqx:forClauseItem>
</xqx:forClause>
...
|
準備就緒，然后該何去何從？
2001
年 6 月，就在第一次重要的發布迭代之后，在我第一次撰寫關于已有 XQuery 實現的總結文章時，當時還只有兩種實現：我自己很早的一種實現和
Microsoft
的實現。于是我給自己找了點樂子，開玩笑說比爾蓋茨和我成了市場競爭中的賽馬師。那個時代已經過去了，經過四年和發布了更多工作草案之后，那個玩笑已經過
時了。現在差不多有四五十種實現了，還有大量的相關產品和工具。
如果要尋找一個實現，最好的地方就是 XML Query 主頁（參閱 參考資料）。這個列表更新很快，隨著興趣和動機不斷增強，隨著規范越來越接近推薦標準狀態，我預料將會不斷出現新的實現。
語法：一個簡單的例子
|
讓我們通過實際的例子快速看一下 XQuery 的一些特性。下面是一個非常簡單的查詢，操作 Use Cases 文檔中的規范示例文件。該查詢展示了 XQuery 投影（在數據集中選擇與所定標準匹配的節點子集）和轉換（生成與正被查詢的文檔不同的輸出文檔）的能力。XQuery 允許在一個查詢中同時指定要搜尋的內容和輸出格式。
清單 3 顯示了查詢操作的文檔的片段：
清單 3. 查詢操作的文檔片段
<bib>
<book year="1994">
<title>TCP/IP Illustrated</title>
<author><last>Stevens</last><first>W.</first></author>
<publisher>Addison-Wesley</publisher>
<price>65.95</price>
</book>
<book year="1992">
<title>Advanced Programming in the Unix environment</title>
<author><last>Stevens</last><first>W.</first></author>
<publisher>Addison-Wesley</publisher>
<price>65.95</price>
</book>
<book year="2000">
<title>Data on the Web</title>
<author><last>Abiteboul</last><first>Serge</first></author>
<author><last>Buneman</last><first>Peter</first></author>
<author><last>Suciu</last><first>Dan</first></author>
</book>
...
</bib>
|
現在希望得到 清單 4 所示的輸出文檔（經過一點美化）：
清單 4. 輸出文檔
<results>
<book authorCount="1">
<author>Stevens</author>
</book>
<book authorCount="1">
<author>Stevens</author>
</book>
<book authorCount="3">
<author>Abiteboul</author>
<author>Buneman</author>
<author>Suciu</author>
</book>
...
</results>
|
下面就是查詢本身。它的任務是掃描查詢文檔中的所有圖書，生成上面所顯示的結果文檔：在輸出的每個新建 <book> 標記中包含計算出的 authorCount 屬性；并丟棄原始文檔中其他大部分信息，只保留每位作者的姓。
（注意，我在這里使用了術語 “查詢文檔”（單數）。這是一種簡化，XQuery 數據模型也能處理文檔集合以及文檔片段。）
清單 5. 掃描查詢文檔中所有圖書的查詢
<results>
{
for $book in doc( "http://uri-for-book-dataset" )//book
let $authors := $book/author
return
<book authorCount="{ count($authors) }">
{
for $author in $authors
return
<author>{ $author/last/text() }</author>
}
</book>
}
</results>
|
清單 5 中，使用 doc() 函數使查詢指向要查找的 XML 文檔。它返回 XQuery 和 XPath 數據模型（XDM）詞匯表中的 文檔節點。
剖析查詢
下面是該查詢的一些有趣特性：
for/let 表達式
該示例包含兩個嵌套的 for 循環和一個 let。外層的 for 循環遍歷擴展路徑表達式 doc(...)//book 得到的每個節點，并將每個 <book> 節點分別放到名為 $book 的變量中。let 表達式選擇每本書的所有 <author> 子節點，并放到名為 $authors 的變量中。$authors 變量保存節點序列，$book 和 $author 變量都包含一個節點。
請務必留意，這些變量不是賦值的 而是綁定的。差別細微但很重要：變量一旦綁定，它的值就不可更改。這可以防止在運行中對變量重新賦值而造成糟糕的負面影響。另一個潛在的好處是，（在某種程度上）可以在處理期間重排包含變量的行，從而允許智能引擎優化它們的查詢。
for 和 let 表達式是 FLWOR（讀作 flower）表達式的子組件。這個縮寫詞代表其五個主要的成分子句：for-let-while-order by-return。清單 6 中，FLWOR 表達式的形式語法為：
清單 6. 帶有 for 和 let 子成分的 FLWOR 表達式
FLWORExpr ::= (ForClause | LetClause)+ WhereClause? "return" Expr
|
表明這是一個變化非常多的表達式類型，能夠生成大量可能的查詢實例。正如該生成所顯示的那樣，"return" 關鍵字后面的 Expr 項本身可以被另一個 FLWOR 表達式替代，因此，可以像不斷加長的 LEGO 積木那樣，將 FLWOR 表達式首尾相接，無限 地排成一行。能夠用任何其他表達式類型替換 Expr 項，使 XQuery 具有可組合性 并給予它豐富的表達能力。XQuery 中有大量表達式類型，每一種可以插入需要更一般的 Expr 的地方。
一般來說，最終會有一個 return 語句結束 FLWOR 序列。在上面的例子中，增加的內部 return 是為了方便插入要輸出的每個 <book> 的元素構造器。
元素構造器
這個查詢包含三個元素構造器。通過將文字尖括號 XML 直接寫入查詢本身的正文中，在查詢過程中動態生成元素 <results>、<book> 和 <author>。
在需要區分文字文本內容和元素構造器中需要計算的子表達式時，使用花括號（{ 和 }）。比方說，如果我們編寫 清單 7 所示的文字表達式則不需要用花括號來分隔內部標記和外部標記。
清單 7. 用括號區分內部和外部標記的代碼
順便提一句，花括號是在 2001 年 7 月修訂表面語言語法時引入的。更早版本的語法不需要花括號。花括號是語言在成為推薦標準過程中不斷修改和演化的一個好例子。
屬性構造器
清單 8 中的代碼顯示了行內屬性構造器的用法。count() 函數返回每本書中包含的 <author> 元素的個數。也要注意這里的花括號，用于將需要計算的表達式和周圍的文字 XML 分開。在屬性構造器中使用引號分隔屬性值是規范演變過程中不斷修改的另一個例子。
清單 8. 使用行內屬性構造器
<book authorCount="{ count($authors) }" >
|
內置函數和運算符
count() 是內置函數的一個例子。“Functions and Operators” 草案列出了大約 12 類 225 種函數和運算符，用于構造和操作各種不同的數據類型，包括數字、字符串、布爾值、日期時間、qname、節點和序列。
清單 9 中的表達式通過 text() 運算符，使用從包圍它的 <last> 元素中提取的姓氏來填充每個 <author> 元素的內容。如果直接使用 $author/last，將同時得到包圍的標記，這不是本例所希望的情況。
清單 9. 使用內置運算符 text()
<author>{ $author/last/text() }</author>
|
|
|
|
參考資料
學習
獲得產品和技術
關于作者
|
|
|
|
Howard
Katz 生活在加拿大BC省的 Roberts Creek，他是 Fatdog Software 公司的所有者，該公司專門開發 XML
文檔搜索軟件。他是 XQEngine 的作者，這是一種基于 Java 的開放源碼 XQuery 引擎。近 35
年來他一直是一位活躍的程序員（一直業績良好），并長期為計算機行業刊物撰寫技術文章。他曾為 Microsoft 撰寫一個在線 Java 專欄，為
Apple 每月撰寫一期關于面向對象編程的專欄文章。他曾任 “溫哥華 XML 開發者協會”
的主持人。他和妻子夏天去海上劃船，冬天去邊遠地區滑雪。您可以通過 howardk@fatdog.com 與 Howard 聯系。
|