IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope: Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  XML  >

XQuery from the Experts: 影响 XQuery 设计的因素

书摘:探索 XML 查询语言的起源

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 初级

Don Chamberlin, IBM Fellow, Almaden 研究实验室

2004 年 1 月 01 日

IBM 的 XQuery 先驱 Don Chamberlin 论述了 XQuery 语言的发展历程,特别是为 XML 数据提供一种查询语言的必要性,以及设计 XQuery 语言的基本原则。本文摘自 Addison-Wesley 最新出版的书 XQuery from the Experts 中的第 2 章。

20 世纪 90 年代,万维网(WWW)的出现成为人类文化中有巨大影响的事件。突然,似乎是一夜间,世界上相当大的一部分计算机被连接在一起,不仅仅通过物理网络,而且还通过一个用于交换信息的公共协议。Web 为信息的真正普遍存在提供了空前的机会。人们似乎有望不再需要为获取信息,进行空间和时间上的物理移动,因为所有信息一直都是无处不在的。

实现该愿望需要一些进行信息交换的组织原则。此原则必须独立于任何特定的语言或应用程序,并易于为新的和未知种类的信息所扩展。目前,首选的组织原则就是可扩展标记语言(Extensible Markup Language,XML)。XML 提供了一个中立的表示法,用于标注信息体的各个部分以及表示各部分间的关系。因为 XML 没有赋予其标签任何语义意义,所以应用程序可以按照合适的方法自由地解释它们。支持通用词汇表的应用程序可以使用 XML 进行数据交换。由于 XML 没有规定任何特定的存储技术,所以它可作为通用交换格式用于各种系统中,而这些系统可在文件系统、关系数据库、对象仓库以及许多其他的存储格式中存储数据。

XQuery from the Experts

本文摘自 Howard Katz、Don Chamberlin、Denise Draper、Mary Fernandez、Michael Kay、Jonathan Robie、Michael Rys、Jerome Simeon、Jim Tivy 和 Philip Wadler 合著的 XQuery from the Experts(0321180607), copyright 2004. All rights reserved. Chamberlin 编写了其中的第 2 章,题为“影响 XQuery 设计的因素”。本文的刊登获得了 Addison-Wesley 的许可。

由于 XML 是作为不同应用程序之间的数据交换的通用格式出现的,所以跨应用程序边界的查询自然也应该按照数据的 XML 表示来构造。换句话说,如果将应用程序视作以 XML 格式表示的信息源,那设置与此 XML 格式相对的查询就是合乎逻辑的。这就是在一个连通的世界中,XML 数据的查询语言为何如此重要的基本理由。

认识到 XML 查询语言的重要性,万维网联盟(World Wide Web Consortium,W3C)于 1998 年 12 月 在波士顿组织了一场名为 QL’98 的查询语言专题讨论会。该专题讨论会吸引了近百名参加者,并且促成了 66 篇研究 XML 数据查询各个方面的论文。讨论会的最终结果就是创建了 W3C XML Query 工作组。该工作组由 Paul Cotton 主持,并于 1999 年 9 月进行了第一次集会。其最初的章程是制定一个形式数据模型和 XML 查询语言的规范,并且与现有的 W3C 标准(如 XML Schema,XML Namespaces,XML Information Set 和 XSLT)是协调的。新的查询语言是为了能提供一个灵活的工具,用以从真实的和虚拟的 XML 文档中提取信息。大约 40 位参加者都成为了该工作组的成员,代表了大约 25 家不同的公司,与 W3C 的工作人员一起提供后勤支持。

Query 工作组的早期活动之一就是起草 XML 查询语言需求的正式声明。该文档还紧跟了一组使用案例,其中描述了使用新语言的不同场景,包括了特定查询和预期结果。XML Query 工作组负责定义一个可选择两种语法的语言。基于关键字的名为 XQuery 的语法适合人们读写,而基于 XML 的名为 XQueryX 的语法则适合机器生成。本文仅描述基于关键字的 XQuery 语法,这也是工作组的主要关注点。

创建新的查询语言是件严肃的事情。已经花费了许多人力和时间来定义 XQuery,并将为其实现花费更多。如果语言成功的话,那么基于 Web 的应用程序的开发人员在未来的很多年里都将使用它。一个成功的查询语言可以提高生产率,并在行业发展中产生一致影响。另一方面,一个设计很差的语言则会阻止大家接受可能很有前途的技术。XQuery 的设计者们十分认真地承担起这个责任,不仅仅是为了各自公司的利益,还为了对整个行业做出一份贡献。

本章着重讨论 XQuery 语言设计时的主要影响。影响 XQuery 的一些因素是计算机语言设计的原则。其他就是相关的语言、接口和标准。还包括了工作组所讨论的“分水岭问题”。而这些问题的解决指导了该语言的发展。我们将详细讨论其中的几个分水岭问题,包括考虑过的可选方案以及选择最终解决方案的理由。

本章基于出版本书时最近制定的 XQuery 规范。这次,可认为该语言的大致轮廓已经相当稳定了。然而,读者应该注意的是,XQuery 的设计工作仍在进行中,在该语言被批准并作为 W3C 推荐标准(recommendation)发布之前,这里所讨论的设计选择很可能会进行修改。

XML 查询语言的需求

在发展早期,XML Query 工作组面临的一个问题是,XML 是否不同于其他数据格式,并且需要它自己的查询语言。SQL 语言是一个用于从关系数据库中检索信息的稳定标准,并且在最近还增加了名为“结构化类型”的新工具,用以支持类似于 XML 中元素嵌套的嵌套结构。如果能够进一步扩展 SQL 来满足 XML 查询需求,开发人员就可以利用 SQL 实现中的大量成果,用户也可以将这些健壮且成熟的系统特性应用到 XML 数据库,而无需学习一门全新的语言。

鉴于这些因素,工作组从查询语言的角度对 XML 数据和关系数据的区别进行了研究。这两种数据模型之间的明显区别总结如下:

  • 关系数据是“平面的”,即它是以具有行与列的二维数组的形式组织的。比较而言,XML 数据是“嵌套的”,并且其嵌套深度可以是不规则且不可预测的。关系数据库可以通过使用结构化类型或带有外键的表,表示嵌套数据结构,但要为不知道其嵌套深度的对象搜索该结构是很困难的。而在 XML 中,可以很自然地搜索到不知其文档层次位置的对象。这种查询比如可以是“Find all the red things”,在 XPath 语言中可用表达式 //*[@color = "Red"] 来表示。而在关系查询语言中,该查询表示起来将会困难得多。
  • 关系数据是规则且同构的。表中的每一行记录都有相同的列,包括相同的名字和类型。这就允许将元数据(metadata),即描述数据结构的信息分解出来,按照单独的类别进行存储。与之相反,XML 数据是不规则且异构的。每个 Web 页面或书中一个章节的实例都可以拥有不同的结构,因而必须描述其各自的结构。因此,在 XML 中元数据到数据的比率要比在关系数据库中高出许多,并且在 XML 中,元数据以标签形式分布在整个数据中,而非与数据分离开。在 XML 中,可以很自然地进行跨越数据和元数据的查询,例如“What kinds of things in the 2002 inventory have color attributes”,在 XPath 中可由表达式 /inventory[@year = "2002"]/*[@color] 来表示。而在关系语言中,这种查询需要进行也许跨越了多个数据表和系统目录表的联接。
  • 与所存储的表一样,该关系查询的结果也是平面的、规则的、同构的。而 XML 查询的结果却没有这些属性。例如,“Find all the red things”的查询结果也许包含樱桃、旗帜和停车标志,每个都有不同的内部结构。一般而言,XML 查询表达式的结果可由异构的元素序列、属性和所有混合类型的原始值构成。这组对象可接着作为中间结果用于处理更高一级的表达式。SQL 假设查询内的每一个表达式都返回一个行和列的数组,而 XML 数据的异构本质与之相冲突。这也需要一种查询语言来提供可动态创建复杂嵌套结构的构造函数,而该工具在关系语言中是不需要的。
  • 由于其规则结构,关系数据是“密集的”,即每一行中的每一列都有一个值。这就产生了对于“空值(null value)”的需要,用以在关系数据库中表示未知的或不适用的值。而 XML 数据却可以是“稀疏的”。因为一个给定类型的所有元素不需要有相同的值,所以未知的或者不适用的信息也就不存在了。这给了 XML 查询语言更多自由度来处理丢失的数据。
  • 在关系数据库中,除了通过其值排列次序之外,表的各行记录不能认为是具有次序的。而 XML 文档却有一个对其含义很重要的固有次序,并且不能来源于数据值。这对查询语言的设计具有多种含意。它意味着查询至少要提供一个选项,用于在查询结果中保存元素的原始次序。它也意味着需要用于按其次序搜索对象的工具,如“Find the fifth red object”或“Find objects that occur after this one and before that one”。它还意味着我们需要一些工具,用于在对象序列上强加一个次序,有可能是在多个层次上进行的。XML 中次序的重要性与关系数据模型中缺少固有次序形成了鲜明对比。

以上所总结的数据模型的明显区别使得工作组决定,最好是设计一种新的查询语言,而不是扩展关系语言来进行 XML 查询。然而,正是由于 XML 数据的复杂性,所以为 XML 设计查询语言就不是一项小任务了。由查询表达式计算出来的 XML “值”,可为零项、一项或者多项,而其中每一项可以是一个元素、一个属性或一个原始值。因此,应为所有这些可能的输入很好地定义 XML 查询语言中的每个运算符。其结果很可能产生其语义定义比关系语言(如 SQL)更加复杂的一门语言。





回页首


基本原则

XML Query 工作组没有起草指导 XQuery 设计的正式原则表。尽管如此,整个设计过程中,工作组至少在设计 XML 查询语言应遵守的部分原则上达成了相当稳定的一致意见。其中部分原则列入了工作组的章程,而其成员对其他原则也深信不疑。下面是我个人列举的最能影响 XQuery 语言发展的基本思想和原则。其中部分原则会有些冲突,然而一些设计决策的产生就是找到了冲突原则之间的合理妥协。

  • 组合性: 也许 XQuery 设计中最长期有效的原则就是,XQuery 应该是一门包含了组合性原则的函数式语言。这就意味着 XQuery 是由多种表达式构成的,如路径表达式、条件表达式以及元素构造函数,是完全通用的。而任何一个表达式的结果都可用作另一个表达式的操作数。虽然语言具有语义约束,但对于表达式的构造方式却没有施加语义约束。每个表达式仅根据其操作数来返回值,并且都不会产生副作用。查询中最外面的表达式所返回的值就是整个查询的结果。
  • 闭包: XQuery 定义为 Query 数据模型上所进行的转换。查询中的每个查询或子表达式的输入和输出都将形成 Query 数据模型的实例。这就是“XQuery 在 Query 数据模型中是 闭包的”这句话所指的意思。工作组花费了大量时间定义 Query 数据模型,以及如何通过输入的 XML 文档构造该模型的实例,并且/或者以 XML 文档形式序列化输出。
  • 模式一致性: 由于 XML Schema 最近已被采用作为 W3C Recommendation,所以工作组认为基于 XML Schema 的类型系统设计 XQuery 是极其可取的。该约束通过提供一组原语类型、类型定义工具和继承机制,极大地影响了 XQuery 的设计。XML Schema 定义的有效过程也极大地影响了用于构造新元素和指派其类型的 XQuery 工具。尽管如此,工作组的成员们还是试图将语言中有关类型定义和有效性的那部分内容模块化,因此将来某个时候,XQuery 还可能用于另一种模式语言。
  • XPath 兼容性: 在 XML 团体中,由于 XPath 的广泛使用,所以我们竭尽全力维护 XQuery 和 XPath V1.0 间的兼容性。尽管该目标很重要,但为了与 XML Schema 类型系统保持一致,有必要在少数领域中牺牲这种兼容性,因为 XPath V1.0 毕竟是基于更加简单的类型系统而设计的。
  • 简单性: 工作组的许多成员认为表达的简单性和易于理解是设计该语言的主要目标。但这两个目标通常会与其他目标发生冲突,从而导致一些痛苦的折中。
  • 完整性: 工作组试图将语言设计得十分完整,足以表达大范围的查询。存在动机良好的用例可以看作是包含一种语言特性的强大理由。XQuery 的表达能力可以与为数据库查询语言定义的“关系完整性”标准相比,虽然还没有为 XML 数据模型定义这样的正式标准。XQuery 被非正式地设计为可以构造 XML 文档,而这些 XML 文档是通过对输入的 XML 文档进行一阶谓词演算得出的。此外,递归函数也增强了语言的表达能力。
  • 普遍性: XQuery 是为了能用于许多不同的环境和使用多种类型的输入文档。该语言应该适用于由模式、文档类型定义(Document Type Definition,DTD)或其他方式描述的文档。它应该既能用于强类型环境(已知输入输出类型且严格强制),也能用于更加动态的环境(可在执行时才发现其输入输出类型,并且可存在未定义类型的数据)。它还应该能适应来自各种数据源的输入文档,而这些数据源包括 Web 上发现的 XML 文件,已预先验证的 XML 文档存储库,诸如股票行情接收机的流式数据源,以及来自数据库中的经过综合处理的 XML 数据。
  • 简洁性: 为了符合其简洁性原则,定义了 XQuery 运算符的语义,使其包括了某种隐式操作。例如,将算术运算符(如 + )施加于某个元素时,该运算符会自动提取该元素的数值。类似地,将比较运算符(如 = )施加于一系列值时,则会自动地对该序列进行迭代,寻找满足比较(此过程称作存在量化(existential quantification))条件的一对值。这些隐式操作与 XPath V1.0 一致,并且比起由用户显式地指定每个操作的设计更为优秀。
  • 静态分析: 从一开始,我们就假定查询过程由两个阶段构成: 查询分析查询计算(大致相当于程序的编译和执行)。分析阶段被视作是执行优化和检测某种错误的机会。我们做了大量工作来定义在分析阶段执行的各种检查,以及确定哪些检查是必要的,而哪些是可允许的。


参考资料



关于作者

Don Chamberlin,Almaden Research Center 的 IBM Fellow,是 IBM 在 W3C XML Query Working Group 中的代表之一。他还是 Quilt 语言建议的提出者之一,而正是 Quilt 形成了 XQuery 设计的基础。Don 是 SQL 数据库语言的发明者之一,并著有两本 DB2 数据库系统方面的书,他也因此而闻名。他拥有 Harvey Mudd 学院的学士学位以及斯坦福大学的博士学位。他还是 ACM Fellow 以及 National Academy of Engineering 的成员。Don 是下列工作草案的编辑: XML 1.0:XML Query LanguageXML Path Language(XPath)2.0XML Query Use Cases。您可以在 Don Chamberlin 的 网站找到更多关于他的信息。




对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

建议?







回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款