Howard Katz 介绍 W3C 的 XQuery 规范，经过幕后长期的深思熟虑后，该规范当前正在迈向建议书状态。这个复杂的规范是由六个独立工作草案（还会有更多）组成。本文提供一些该规范涉及到的某些技术问题的背景、文档导读和概述。副栏快速浏览了 XQuery 表面语法的某些关键功能。代码样本演示了 XQuery 和 XQueryX 之间的区别并给出表面语法示例。

　　W3C 的 XQuery 规范已经进行了很长时间。W3C 于 1998 年 12 月在波士顿主办了开启工作的最初查询语言讲习班。来自业界、学术界和研究团体的受邀代表得以有机会在该讲习班上对他们认为在 XML 查询语言中重要的特性和需求发表看法。

　　两个不同的阵营

　　66 篇演讲稿，都可以联机获取（请参阅参考资料），主要来自两个不同的阵营：那些主要工作以文档形式使用 XML 的领域中的人（很大程度上 反映了 XML 在 SGML 中的原始根基）和以数据形式使用 XML 的人 — 后一种很大程度上反映了中间件领域、前端传统的关系数据库中 XML 不断增长的比率。

　　俄勒冈州研究生院的 David Maier 用特别简明扼要的方式写了一篇名为“Database Desiderata for an XML Query Language”的讲演稿，多次向我提到可以将它作为这些文档之一，即特别有助于知道波士顿讲习班之后任命的“查询语言工作组”的想法。

　　按 W3C 标准，该工作组是庞大的（有人告诉我只有“协议工作组”有更多成员）。其 30 多个成员公司的构成反映了这两种阵营的观点。现在开始结合到最终形式的是一个 XML 查询语言标准， 该标准很好地代表了两个团体的需要和观点。

　　XML 用户最熟悉的 XQuery 关键组件将是 XPath，它本身就是 W3C 规范。自己独立存在的单独 XPath 位置路径 （"//book/editor" 意味着“在当前集合中查找所有书刊编辑器”） 是非常有效的 XQuery。在数据方面，XQuery 类似于 SQL 的外表和能力将会受到以前使用关系数据库的用户的欢迎和熟悉。

　　其卑微的起源

　　XQuery 是从 Quilt 开始的，Quilt 是三位工作组成员共同努力的结果，他们是：Jonathan Robie、Don Chamberlin 和 Daniela Florescu。Robie 最著名的成就大概在于率先标准化和推动 XQL，XQL 是 XQuery 的前身和当前 XML 查询语言世界中最接近实际标准语言的一种语言，有十几种在使用的实现方法。Chamberlin 是 SQL 的共同设计者之一（在简历上是值得骄傲的！）和 IBM 研究团队的一员，如其网站所言，“该团队开发了大量当代关系数据库技术”。Florescu 也不逊色。她的网站显示，其在近 10 年之内，她撰写或与人合著了 50 多篇关于查询语言优化和体系结构拓展的研究论文。

　　这三位作者引证了有关 Quilt 的设计的语言影响，包括 XQL、XML-QL 和 SQL。"XML Query Language: Experiences and Exemplars"（请参阅参考资料）是一篇有用的论文，提供了前两种语言以及称为 YaTL 和 Lorel 的两种其它语言作了很好的比较性概述，该论文由 Mary Fernandez、Jerome Simeon 和 Phil Wadler（工作组的所有人）合著。

　　由于数据和文档社区的不同观点以及打下的牢固基础（下面有详细描述），花费如此长的时间才将大部分规范向大众公布也就不足为奇了。W3C 工作组的内部事情是机密的，并且在二月中旬以前，大多数“查询语言工作组”的工作都是闭门完成的。

　　很早就发布了“需求”文档和“数据模型”工作草案（后者自 2001 年 7 月起才有一个主要更新），但是直到 2 月中旬，工作组的发布工作才得以充分进行。至 2001 年 2 月中旬止，已经发布了大部分文档。

　　新生的发布王国

　　到此为止，已经交付了总共 6 个工作草案，还有一篇即将交付（“XQuery 功能和操作符”文档）。包括已经提到的两篇， 描述和定义 XQuery 的所有文档集现在包括：

　　XML 查询需求

　　工作组规划文档。XQuery 需求列表。

　　XML 查询用例

　　解决特定问题的几个实际方案和 XQuery 片段。

　　XQuery 1.0：XML 查询语言

　　中枢文档，介绍语言本身和大部分其它内容的概述。

　　XQuery 1.0 和 XPath 2.0 数据模型

　　XML 信息集扩展。描述查询实现必须理解的数据项和形式语义的基础。

　　XQuery 1.0 形式语义

　　形式上定义语言的基本代数。

　　XQuery 1.0（XQueryX）的 XML 语法

　　为喜欢使用 XML 的人提供的另一个语法。任何地方的机器都愿意使用。

　　这些文档（在参考资料中均有引用）代表了大量工作。XQuery 1.0：“XML 查询语言”是 该集合的关键，但是其它文档为 XQuery 成为相当惊人的良好指定和全面支持的语言作出贡献。就我所知，这将是出自 W3C 的最复杂的一套规范（虽然“XML 模式”也许可与之相比，但是这是另一回事了…）。

　　如果第一次接触如此数量的文档，并想知道从何处着手，我可以推荐两种方法。可以从中枢 XQuery 1.0 文档开始。它有一个很好的介绍性概述。另一个方法是从使用“用例”工作草案开始。本文档列出了可以应用 XQuery 的几个实际方案。每个用例都以特定应用领域为目标，并列出大量针对该领域的样本数据而提出的可能 XQueries。如果想查看实际工作语法的具体示例，则这些代码片段是十分珍贵的。

　　BabelFish，你在哪？

　　XQuery 比 Certs 更出色：它实际上是三个语言合一。首先，有“表面”语法，它是三个中可视性最高的并且是用户最有可能与之发生联系的语法。（请参阅副栏语法：快速取样器中的表面语法）。其次，有一种可以替换表面语言的基于 XML 的语法，它对于机器处理有更强的可跟踪性。（请参阅本文后面的 XQueryX。）最后，有一种形式代数语言，它十分详细地描述了 XQuery 处理器的内部工作。

　　基本形式方法

　　“数据模型”和“形式语义”工作草案一起为 XQuery 提供了精确和理论上的支撑。这两个文档详细介绍了查询代数，用形式术语定义的一组精确定义、XQuery 查询期望操作的核心实体以及各种语言操作符可使用那些操作数进行操作的公式。您可能对它不感兴趣，除非您是查询引擎的实现者，有较多的经费保障或者只是喜欢使用复杂的形式系统。

　　提供了一个映射，它使实现者能够将表面语法特性直接重造成基本代数。正如 4 月份在 纽约召开的一个 XML 会议上几家供应商提出的那样，可以直接实现实际使用代数的查询处理器（虽然我认为对于概念证明这已足够）。参考资料中的链接指向这些基于代数引擎之一的一个联机演示版本。

　　代数还提供了详细描述如何将复杂表达式优化和转变成更简单的等价形式的规则。我所能做的最好评价是，这两者都是不错（我不是语言理论家，并且“形式语义”文档并不象读起来那样轻松）。大型数据库供应商会赞赏从底层开始设计成是可优化和有效的查询语言体系结构。

　　代数还提供挂起类型信息的位置。XQuery 是强类型的：如果数据有与其相关的“XML 模式”，则处理可以根据该模式验证，并提供带有关于文档中节点数据类 型的 Post-Schema-Validation-Infoset（PSVI）信息的查询引擎，利用“XML Schema Part 2: Datatypes”中声明的类型和自定义的用户定义类型。代数有静态和动态类型检查能力。引擎可以使用取自 PSVI 的类型信息，例如，以在编译时静态地检查查询表达式的数据类型（当分析查询的语法正确性时）。在循环中尽早确定类型无效的查询，就缩短了对大数据集进行潜在的、花费巨大的（和无结果的）搜索的需要。

　　XPath 2.0 和剩余问题

　　XQuery 与 XPath 2.0 共享一种公共数据模型，这在数据模型文档的有点尴尬的标题“XQuery 1.0 and XPath 2.0 Data Model”中有所反映。XPath 2.0 还未完全成熟。数据模型仅描述 XML 文档中 XPath 处理器感兴趣的核心信息，XPath 步骤操作的最终语法和语义还需要详细制定。全部规范归“查询语言”和 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 保持一致时，需要他们协同工作。

　　什么时候才有可能解决剩余问题？我不知道。在 6 篇工作草案其中 4 篇的附录中清楚地列出了 问题列表，并且自从 2 月早先发布的迭代以来，这些问题列表还有所增加。一个月前，工 作组主席 Paul Cotton 公开想法，他期望 XQuery 在年底前达到“建议书”状态。我不知道这是否仍然可行。

　　XQueryX

　　最新加入 XQuery 文档系列的是 XQueryX，替换表面语言的基于 XML 语法的规范。XQuery 的一种需求 声称多语法是也许有可能的 — 听起来象是工作组为防止损失下了点注 — 如果是这样，这些语法中的一个可能必须方便人们读写，另一个可能必须可用 XML 表示。

　　基于 XML 的查询表示具有 XML 所有明显的和已知的优点：它使标准工具易于对查询语言进行语法分析并生成和询问查询内容。这可能很有用，例如，如果正在做源码级优化或变换，这可能依次取决于方便地检查查询的特殊语法结构的能力。我们知道 XML 擅长这类任务。

　　我怀疑语法的第一版不会变成一成不变地处在“建议书”状态。首先，它是极其冗长的。引起注意的是虽然 XML 的最初设计目的使简洁的重要性最小化，但“XQuery 需求”文档未提及该问题。从产品判断，冗长似乎占了上风。它是否将继续主导地位还不确定；在 XQueryX 规范结尾的“问题”列表中的一个术语对于该格式是否应该比它现在更简洁或更具可读性提出了疑问。我猜工作组将最终向该方向发展。

　　清单 1 显示 XQuery 语法格式的简单查询：

　　清单 1. 标准语法格式的简单查询

  LET $authors := /book/author
   RETURN
      <AUTHORS>
      {
         $authors
      }
      </AUTHORS>

　　而清单 2 显示 XQueryX 格式的等同示例：

　　清单 2. XQueryX 格式的相同查询

<q:query xmlns_q="http://www.w3.org/2001/06/xqueryx">
      <q:flwr>
         <q:letAssignment variable="$authors">
            <q:step axis="CHILD">
               <q:identifier/>
           <q:step axis="CHILD">
                  <q:identifier>book</q:identifier>
                  <q:identifier>author</q:identifier>
               </q:step>       
            </q:step>         
         </q:letAssignment>
         <q:return>
            <q:elementConstructor>
               <q:tagName>
                  <q:identifier>AUTHORS</q:identifier>
               </q:tagName>
               <q:variable>$authors</q:variable>
            </q:elementConstructor>
         </q:return>
      </q:flwr>
   </q:query>

　　冗长不会对该语法的机器有影响（除非我们在讨论相当大的查询），但是操作员进行实际调试时将面临一些困难。

　　次要警告：上述“/book/author”位置路径的语法有一些我的主观猜测成分；附录中 DTD 和模式有关这种表达式类型的确切语法有一点不清楚。这是使用早期规范的缺陷的一个实际教训。

　　准备就绪，然后该如何呢？

　　不幸的是，如果想立即有一些上机实验经验，却没有太多可用的选择。目前基本上只能选择我或微软了。（有些人一定忠实于微软，我参加了该工作。）我 自己的“XML 查询引擎”（请参阅参考资料）实现了一个 XQL 前端。最近，我添加 了早期的 XQuery 支持，主要因为我想使用该语言并对实现它的难度产生了好奇。我可以说，虽然语法上我没有天分，但也不是那么困难。

　　Web 上有一个微软联机查询引擎演示（请参阅参考资料）， 那是他们 .NET 工作的一部分。用 C# 编写、并且目前符合 2 月 15 日的规范（和我的一样），您可以对“用例”文档中的所有示例运行封闭查询。我的引擎至少可以让您对实际数据进行查询。我在等待微软的下一步行动。

　　参考资料

　　通过单击本页顶部或底部的讨论来询问有关本文的问题或进行评论。

　　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 Formal Semantics。形式上定义查询引擎行为的基本代数。

　　XML Syntax for XQuery 1.0 (XQueryX)。机器喜欢的另一种 XML 查询语法。

　　QL98: Query Languages Workshop。最初关于查询语言的波士顿讲习班的 W3C 网站。

　　Database Desiderata for an XML Query Language，David Maier 在讲习班上的讲演稿。

　　XML Query Language: Experiences and Exemplars，Fernandez、Simeon 和 Wadler。对用 XML-QL、XQL、YaTL 和 Lorel 表示的 10 种“必不可少的查询”的比较。

　　XML-QL: A Query Language for XML，Deutsch、Fernandex、Florescu、Levy 和 Suciu。对 XQuery 的影响。

　　XQL FAQ，由 Jonathan Robie 维护。

　　XML Query Language: A Proposal，Robie、Lapp 和 Schach。对 W3C 的 XQL 建议。

　　Quilt。Don Chamberlin 的网站。

　　XQuery 代数演示网站。贝尔实验室中 Jerome Simeon 的基于代数的查询引擎演示。有些过时，但是将“很快”被更新成当前规范。

　　XML 查询引擎。作者自己的查询引擎中对于 XQuery 的较早支持，自由下载资源的一部分。FLWR 的元素构造器和基本 xpath 表达式。

　　XML Query Language Demo。Microsoft 的联机 XQuery 演示。目前符合 2 月 15 日的规范，该引擎对用例的封闭版本适用。

　　XML Schema Part 2: Datatypes。XQuery 理解的数据类型。

　　IBM 的 DB2 Extender 页面给出 了 DB2 如何使用 XML 的概述，带有到有关如何用 XML 进行查询的白皮书（可用 PDF 查看） 和到 DB2 Extender 下载的链接。

　　Solutions 2001 开发人员大会于 8 月 13 日到 18 日在旧金山召开；请在 AgendaBuilder 中搜索或浏览对 230 多个会议所作的描述。有 20 多个关于 XML 或与之相关技术的会议，包括：

　　Hands-on: Integrating XML with DB2

　　Hands-on: Voice XML Tools/Building Killer Apps

　　XSL by Example: An Introduction to XML Transformations

　　Parsing and Programming XML Documents using Java Technology

　　请参与包含 17 个问题的 有关开发习惯的调查以帮助 IBM 改进开发软件应用程序的 XML 工具开发和服务。

　　语法：快速取样器

　　让我们在实际示例中快速查看 XQuery 功能。这里有一个简单的查询，它对“用例”文档中的规范样本文件执行操作。该查询演示了 XQuery 投影（选择与期望的标准匹配的节点的子集）和变换（生成与正在被查询的文档不同的输出文档）的能力。XQuery 允许您在同一查询中指定要搜寻什么并指明应该具有什么样的输出格式。

　　下面是这个查询所操作的文档片段：

      <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>

　　下面是我们希望产生的输出文档（进行了一些美化）的外观：

     <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 的数据模型还有能力处理文档集。

 <results>
   {
      FOR $book IN //book
      LET $authors := $book/author
      RETURN
         <book authorCount={ count($authors) }>
         {
            FOR $author IN $authors
            RETURN
               <author>{ $author/last/text() }</author>
         }
         </book>
   }
   </results>

　　另外请注意，查询本身不指定执行查询的文档或数据上下文。该上下文由正在使用的特定查询引擎确定。

　　剖析查询

　　下面是该查询的一些有趣功能：

　　FOR/LET 表达式

　　该示例包含两个嵌套 的 FOR 循环和一个 LET 循环。外部 FOR 循环在每一个由扩展路径表达式 //book 所得到的节点上循环，并依次将每个 <book> 节点隔离在名为 $book 的变量中。LET 表达式依次在名为 $authors 的变量中获取每本书的所有 <author> 子节点。$authors 变 量拥有节点序列；变量 $book 和 $author 都拥有单个节点。

　　请务必留意，这些变量不是分配的而是绑定的。差别细微但很重要：一旦绑定了变量，它的值就不可更改。它可以防止由运行中为变量重新赋值而造成的糟糕的负面影响。另一个潜在的好处是，可以（在某种程度上）在处理期间重排包含变量的行，从而允许聪明的引擎优化它们的查询。

　　FOR 和 LET 表达式是 FLWR（读作 flower）表达式的子组件。FLWR 表达式的正式语法：

　　FLWRExpr ::= (ForClause | LetClause)+ WhereClause? "return" Expr

　　显示它是一个变化多端的表达式类型，可以生成大量不同的查询实例。正如该产品所显示的那样，“return”关键字后面的 Expr 项本身可以被另一个 FLWR 表达式替代，因此，可以象不断延长的 LEGO 积木那样，将 FLWR 表达式首尾相接，无限地排成一行。用任何其它表达式 类型替换 Expr 项使 XQuery 可编辑并给予它丰富的表达功能。XQuery 中有大量表达式类型，可以将每一种表达式插入到需要更通用的 Expr 的语法中。

　　一般情况下，最终 RETURN 将终止 FLWR 序列。在上面的查询示例中，附加的内部 RETURN 作为一个方便的插入点，插入每个正在输出的 <book> 的元素构造器。

　　元素构造器

　　这个查询包含三个元素构造器。通过将文字尖括号 XML 直接写入查询本身的主体中，在查询过程中，生成元素 <results>、<book> 和 <author>。

　　在需要区分文字文本内容和元素构造器中需要求值的子表达式时，使用花括号（ { 和 }）。如果我们正在编写如下所示的文字表达式，

  <authors>
       <author>
          …

　　则不需要花括号来分隔内部标记和外部标记。

　　顺便提一句，花括号是 7 月 7 日语法的新需求。较早版本的语法不要求它们。

　　属性构造器

　　行

　　<book authorCount={ count($authors) }>

　　演示了内置属性构造器的用法。count() 函数返回每本书包含的 <author> 元素数。请再次注意花括号， 它在这里用来包围需要求值的表达式。

　　内置函数和运算符

　　count() 是内置函数的一个示例。尚未问世的文档集中的一卷据称是一篇“XQuery 函数和运算符”文档。

　　text() 运算符在表达式

  <author>{ $author/last/text() }</author>

　　中用来从包围姓氏的 <last> 元素中取出姓氏文本，并用该文本填充 每个 <author> 元素的内容。如果直接使用 $author/last，还会获得包围它的标记，这并不是我们想要在该示例中得到的。