揭穿 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 面临着一些困难，但是学习曲线并不很陡峭，也不长。