中文XML论坛--[转帖]揭穿 XQuery 的神话和误解

贴子主题： [转帖]揭穿 XQuery 的神话和误解

本主题类别:

XQuery 给软件架构师和开发人员带来了很多希望，因为大大减少了建立使用 XML 的服务所需要编写的代码量。您也许认为 XQuery 所做的一切很容易理解，但是在 XQuery 的软件开发社区中仍然存在着错误的想法和误解。Frank Cohen 在本文中详细剖析和澄清了围绕着 XQuery 的很多神秘色彩和误解。

　　如果您在使用 XML、Web 或者面向服务的架构（Service Oriented Architecture，SOA），那么很可能会从 XML Query (XQuery) 标准的制定中受益。虽然 XQuery 还未批准为正式标准，但已经有几十种实现每天都在帮助软件架构师和开发人员了。即将形成的 XML 文档查询标准包括了下一代 XML 选择语言（XPath 2）、XML 序列化、全文检索和功能性 XML 数据建模。这样规模的项目免不了有很多神话和误解需要揭穿。下面是围绕着 XQuery 的一些常见的神话和误解。

　　误解：数据库公司将 XQuery 视作其核心业务的直接对手

　　数据库公司将 XQuery 看作一个机会，与其核心解决方案互相补充。

　　对于软件架构师和开发人员而言，XQuery 提高了生产率，增加了敏捷性。工具供应商迫切希望支持 XQuery 是合情合理的。

　　对于开发人员来说，XQuery 很像 SQL，自然而然地对两者加以比较。何况越来越多的数据正使用 XML 标记，这就迫使数据库公司在产品中增加 XML 存储、持久性和查询的能力。XQuery 拥有如此众多的开发人员支持，以至于 IBM 和 Oracle 将它们的角逐放在一旁，转而扩展其核心数据库产品以提供 XQuery 能力。

　　数据库公司也看到了成为第一个充分利用 XML 格式的数据库供应商（从而最终成为市场霸主）所带来的机会。目前存储在关系数据库中的数据按照行和字段进行了规格化。在 XML 世界中，每一行包含无限多个字段，每个字段都是父/子层次结构中的一部分。最先提供高性能和 XQuery 灵活性的供应商将赢得一个巨大的新市场。

　　一个证据是，XQuery 将 IBM 和 Oracle 团结在一起（不再是凶狠的对手），合作提出 JSR 225（参阅参考资料）， XQuery API for Java (XQJ)。在 .NET 这一边，Microsoft 和 IBM 共同向万维网联盟（W3C）提交了 XQuery 测试包。

　　神话：XQuery 将代替 XSLT

　　XQuery 和 XSLT 都有足够多的开发人员支持，将共存下去。事实上，XQuery 1.0 和 XSLT 2.0 最新规范的开发是先后进行的。

　　XQuery 和 XSLT 交叉之处在于它们解决的问题：XML 数据转换、XML 集合联邦和 XML 数据高级查询。开发人员仍仍将看到关于这两种技术的争论，包括各种各样的神话和误解。比如，我常常听说 XQuery 能够一次查询多个不同的源文件，因此要比 XSLT 优越得多。事实上，XSLT 2.0 处理程序允许在输入队列中给出多个节点。 XSLT 1.0 有 document() 函数，可以在一次转换中访问多个源文件，XSLT 2.0 还支持新的 collection() 函数。我也常常听到这样的说法，虽然 XQuery 的语法看起来更好，但是缺少 XSLT 模板风格的模式匹配。虽然这也许是真的，但我坚信 XQuery 也会增加这一功能。最终，开发人员可以预期这两种技术的改进和竞争将使它们的功能和能力不相上下。

　　最后，还有开发人员头脑迟钝的问题。参加的那些 XSLT 会议让我感到，我并没有真正理解它。 XSLT 的转换语法并没有像 Java 和 Jython 中通常所用的 main() 或 start 方法。我有时候将 XSLT 看作一种脚本，说明并没有真正理解 XSLT。XQuery 看起来很像 SQL，解决了很多我不得不从书架上翻找答案的问题。

　　神话：XQuery 将代替 SQL

　　XQuery 最适合于 XML，就像 SQL 最适合于关系数据。 XQuery 为需要访问、挑选、集成和转换一个或多个 XML 集合的应用程序提供了类似于 SQL 的查询能力。虽然 XML 的狂热者可能将世界上的一切都看成是用 XML 标签编码的，单关系数据库模型仍然根深蒂固，世界上大部分数字数据是用由行和列组成的表来进行编码的。SQL 不会很快地消失。相反已经出现 XQuery 扩展，将 SQL 调用的结果看作是 XML 文档集合的一部分。

　　如上所述，XQuery 对于 XML 就像 SQL 对于关系数据库。但是，有些时候甚至相对于关系数据库而言，XQuery 更容易使用。比方说，对于一般开发人员，使用 SQL 创建输出结果为新 XML 文档的多表外连接查询要比编写 XQuery 复杂得多。

　　XML 的普及已经迫使标准团体工作组扩展 SQL 规范，以便纳入 XML 处理功能。 SQLX Group、INCITS H2 小组和 ISO/IEC JTC1/SC32/WG2 的 SQL/XML 标准化都在致力于扩展 SQL 标准，使其能够处理 XML 数据。

　　误解：采用 XQuery 必须放弃过程性编程而转向面向对象编程

　　对于 XQuery 来说，过程性脚本语言和面向对象的编程语言都是一样的。如果愿意编写 PHP 脚本，仍然可以继续这样做。多数现有的编程语言都有 XQuery 实现。
　　XQuery 给开发人员带来的好处是减少了执行查询所需要的代码量。有时候关系数据在两个或更多的数据库中，开发人员需要生成报表来显示两个数据库的并。喜欢使用 Python 这类过程性编程语言的开发人员可能要编写 100 或更多代码行来检索、解析和处理数据。当然也可以编写几行 XQuery 来完成。

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

　　XQuery 用于 XML 数据并不比 XML 解析 API 更难。JDOM、JAXP 以及其他 XML 解析 API 提供了处理 XML 数据的 Java 代码和方法。很多面向对象的设计模式都准备编写处理 XML 文档复杂性的对象。编写 Java 对象需要时间、精力和专门的技能。底层 XML 数据格式的任何细微变化都需要修改对象。XQuery 的拥护者可以肯定地说，和使用 JDOM 编写 Java 对象相比，XQuery 脚本能够更快地发现应用程序需要表示的 XML 数据。另外，很多 XQuery 库都提供了 Java 接口，因此可以在 Java 类中编写 XQuery 代码来获得结果集，就像调用一个方法一样。然后让 Java 类处理结果。

　　神话：XQuery 难以学习

　　使用 Java、.NET 和其他语言的软件开发人员发现 XQuery 很容易学。XML 有很多不那么优美的地方，包括从早期的 SGML 标准继承下来的那些部分。 XQuery 使用一组简洁的命令，很容易处理 XML。虽然一般开人员要掌握 XQuery 面临着一些困难，但是学习曲线并不很陡峭，也不长。

误解：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 的开发人员带来更多的好处。


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	109.375ms