IBM WebSphere 7 添加 XPath 2.0，XSLT2.0 和 XQuery 1.0 支持

IBM 的 WebSphere 功能包是可选择的安装产品扩展，为应用服务器提供了新功能。IBM最近发布的 XML 功能包为应用开发者提供了对最新生效的的 W3C XML 标准集的支持：

• XQuery 1.0: 新引入的查询和函数式编程语言，为查询 XML 数据集合而设计。它使用 XPath 表达式语法来访问一个 XML 文档的特定部分，并且有“FOR，LET，WHERE，ORDER BY 和 RETURN”表达式作为补充。通常缩写为"FLWOR"的这些表达式可以被用于以类似 SQL 的方式执行跨多个 XML 流的连接。
• XPath****2.0: 一个用于 XML 文档的表达式语言。一个 XPath 表达式的结果通常是从输入文档选择出的节点或者是原子值。XPath 2.0 现在是 XQuery 1.0 的一个子集。XPath 1.0 到 XPath 2.0 最引人注意的一个改变是引入了更加丰富的类型系统：每个值现在都是一个序列，一个单一的值将被视为长度为 1 的序列。XPath 2.0 支持“模式认知”，意味着树的元素有类型注解，可以用于 XPath 导航。 一个解析器必须为内建的类型比如字符串，数字，日期等等提供模式认知。作为可选项，也有可能支持用户自定义类型，这将极大的简化所要求的表达式。例如，一个因特网邮件服务公司可能有一个 XML 文档，内容是与客户订单挂钩的记帐地址与投递地址。如果两个地址域都有一个公共的 AddressType，表达式 **//element(*, tns:AddressType)/postalCode** 将会返回两个地址的邮编。XPath 同时还提供强大的功能扩展集和操作符。新的功能包括用于模式匹配的正则表达式语法，新的日期函数比如当前日期，还有新的算术函数比如 floor，ceiling 和 round。新的操作符包括 intersect 和 except。
• XSLT 2.0：一种用于将 XML 转换为一种新 XML 格式，或其它的表示格式，比如 HTML,XHTML 或 SVG 的编程语言。如 XQuery 1.0 一样,XSLT 2.0 也使用 XPath 2.0 作为路径解析语言。XSLT 2.0 加入了一系列的功能，包括 grouping——从一个单一的输入文档输出多个结果的能务，以及在 XSLT 中定义可以被 XPath 调用的函数的能力。 因此一个 XPath 2.0 解析器或者 XSLT 解析器可能会是“模式认知”的。这样将会带来许多优势，比如在 XSLT 转换前可以检验输入树，并且可以检验输出树以合格证 XSLT 转换产生正确的结果。 你可以可以为变量指明数据类型，输入参数，来自函数的返回值，用户自定义函数以及模板。XSLT 继续成为转换 XML 数据的主流选择，而 XQuery 有望成为查询 XML 文档的标准。由于 XQuery 与 XSLT 2.0 两者都使用 XPath 2.0 作为路径解析语言，XQuery 对于 XPath 2.0 的扩展对于 XSLT 开发者来说就无关了。

为了寻求该功能包的更多细节，InfoQ 采访了它的首席架构师，Andrew Spyker：

InfoQ:XML 显而已见已成为在企业计算中广泛应用的格式。你能给我们提供一些例子，哪一类型的应用中这些标准的新功能有可能会引起特别注意？

XML 已在企业计算中非常流行的前提下，要讨论能用到这一功能包的每一个场景将非常困难。因此，下面要提到的并不是所有——而只是作个说明。 查询和表示来自于 XML 源数据的应用。例如，博客 feed，评论以及与 feed 相关的分析。你可以考虑这样一个应用，它挖掘你所有的博客，查找有问题的评论内容，再将这些信息表示为 web 表格的形式，允许你调查其趋势并将特定的评论者标记为不受欢迎的。不断发展下去，你会选择将这一列表存储在数据库里，这样就可以先行一步判定不受欢迎的评论。由于这一场景里所有的输入源都是 XML 和 XHTML(XSLT 2.0 里新支持的序列化格式) 可以方便地被用于 web 展示，使用基于 XML 的编程模型再自然不过。在功能包里有一个示例应用就演示了这一点。

使用业界标准模式的应用。几乎每个垂直行业都要与业界标准模式打交道，并且许多企业都扩展了这些模式来定制自己的业务。在过去，使用 XPath 1.0(并且依赖于 XSLT 1.0)，XML 运行时不知道模式知识。这意味着如果你查找所有 PurchaseOrder 类型的数据元素，你必须在你的搜索中硬编码每一个可能吻合的名字。即使最好的情况下这也会带来代码维护的困难，而最坏的情况当企业扩展现有类型而引入新类型时，脆弱的代码就会失效。而在 XPath 2.0 (以及相关的 XSLT 2.0 和 XQurey 1.0 中)，你可以在查询中根据类型搜索。

使用 XPath 1.0 和 XSLT 1.0 的应用。这似乎是显而易见的，但也值得单独提出来。XPath 2.0 和 XSLT 2.0 考虑了业界使用 7 年以来积累的经验。新功能提供了许多新的功能性场景 (一些例子是：多种语言的比对支持以及 XSLT 2.0 的多输出)，这些之前是不可能做到的。 同时，这些能力还加入了对模式的支持，而这些模式用 XSLT 1.0 表达则过于复杂 (例如，grouping 的支持)，这些支持将会使得代码减少，易于维护并会比以前执行得更好——因为现在是运行时提供支持而不是在运行时之上编码。

跨多个数据源查询数据的应用。尽管一些原生支持 XML 的数据库有时也支持 XQuery(DB2 pureXML 即是一例)，但在中间件级别支持 XQuery 可以允许在这些 XML 数据库与数据库之外的 XML 存储之间进行连接。 一个例子是一个批处理文件，处理一个 XML 数据库的数据，并通过调用 Web 2.0 API 来丰富数据，然后将其存储到另一个数据库。 该 XML 功能包通过一个可以在服务器 JVM 环境之外的标准 Java SE 应用瘦客户端来支持这一场景，只要它以支持应用服务器功能的方式被使用。

如我之前所说，有很多可能的应用场景。所有可能的应用只局限于企业所存储的 XML 数据或文档——而这是非常巨大的。

InfoQ: XSLT 2 和 XQuery 1 这样的语言处理 XML 相比 Java DOM 模型在多核或者云计算的环境里有什么优势呢？

使用如 XML 功能包所支持的声明式 (vs. 命令式) 的以 XML 为中心 (vs. 以语言为中心) 的语言主要有两大方面的优势。 首先，声明式编程询问用户他们想要做什么事。这与命令式编程是相反的 (例如，操作 DOM 或 JAXB API 的 Java 代码)，询问的是用户想要如何实现他们想做的事。Declarative programming leads to smaller, 声明式编程带来的是可适应快速变更的更精简，更易维护的代码。它同时还支持用户向 XML 运行时表达他们的兴趣，或者是他们想要如何查询或转换数据，这种方式运行时可以进行优化，而如果用户直接告诉运行时具体怎样执行则无法做到优化。这一区别在多核及云计算的环境下非常重要，你可以想像得到，优化不仅仅能认出可以单核 CPU 下执行更出色的模式，在多 CPU 或跨虚拟环境的条件下也能出色的执行。 还有，因为 XSLT 和 XQuery 是函数式并且无副作用，你可以完全安全地执行这样的优化——而在命令式语言里使用典型的编程 API 是无法做到这一点的。另外，我个人相信，从长远来看，高级的声明式语言会更加迎合云计算，因为它们比那些假设特定运行时环境的低级语言可移植性更强。

第二点，以 XML 为中心 (vs. Java 或 C#等其它语言)，就是将 XML 类型系统作为核心类型系统。 将 XML 类型系统映射为原生语言的类型系统有两方面的劣势。首先，有一个 XML 保真性的问题。将 XML 映射为对象表示十分困难，稍不注意就有可能造成信息的丢失。像 JAXB2.0 这样的 API 处理这类问题非常棒，但到最后映射成一个完美的无损的 XML 表示，对比纯 XML 模型并不见得有什么好。 其次，因为我们转换了类型系统或转换成 DOM 模型，我们加入了显著的性能开销。本质上这意味着数据拷贝，这在中间件是十分昂贵的操作应当予以避免。而以其原生的表示使用 XML 数据，我们可以保证没有数据丢失而且性能最优。鉴于 XML 作为业务与企业间的数据交换格式如此流行，拥有这两个益处是十分重要的。

我应该说明我们理解人们不会将现有的应用全盘转变成 XML 编程模型。 因此，我们允许以一种简单的方式来将现有的 Java 数据和逻辑添加到 XML 运行时的执行。这一扩展是通过同一个一致的 API 来完成的，而不管使用的是哪一种 XML 语言。这一一致性是重要的，它统一了跨三种语言的编程体验，并且支持数据可以从 XQuery 1.0 到 XSLT 2.0 有效的流水。 我们同时还设计了 API，以保证这一技术简单高效的多线程服务器应用。 之前的 XML API 是为客户端环境而设计的，相对于支持高效多线程编码而言更倾向于单一调用的简洁性。我们的 API 为所有的共享对象加入了线程安全，使得为服务器运用编程更加自然高效。

InfoQ：就操作 XML 而言，W3C 标准与微软的 LINQ 相较而言如何？

一个关键的区别在于 XML 功能包实现的是公开制定的 W3C XML 处理标准。有着这样的一个标准作为根基，组织和开发者就可以更好的跨该标准的多种具体实现而利用这种一致的 XML 编程模型技术和工具。

InfoQ: 该功能包相对于 Michael Kay 的 Saxon 实现有什么优势？

先让我首先解释一下我观察到的所有来自业界的反馈——Saxon 是非常优秀的 XPath 2.0，XSLT 2.0 以及 XQuery 1.0 实现。同时，Michael Kay 与来自 IBM 和其它公司的贡献者一道，在驱动 XML 的 W3C 标准化方面作了许多工作。 Saxon 及 XML 功能包都是实现的相同的标准集。所以从编程模型的角度来看这里保持了一种一致性。从运维的角度，WebSphere 客户可以得到一个背后有 IBM 支持的 XML 实现，他们现有的 WebSphere Application Server V7 权利范围内的测试及支持也将得到保证。 就像我们上面所谈到的一样，我们可以看到许多客户想要在 WebSphere 之上实现基于 XML 的解决方案的应用场景。意识到这一点，我们想要以这样一种形式来提供支持这些标准的新功能，那就是我们的客户不管是现在还是将来都可以信赖它们。

InfoQ：你觉得什么时候我们可以看到这些技术能够融入 Java 平台而得以标准化？到那时你的实现将会怎样呢？

目前，Java 通过 JAXP 支持 XPath 1.0 和 XSLT 1.0，但不支持 XPath 2.0 和 XSLT 2.0。同时，还有一个支持 XQuery 1.0 的 JSR 叫作 XQJ。今后我们应当考虑在 Java 中实现普遍化的 XQuery。 个人而言，我比较担忧面向连接的 XQJ API 以及用户要多大的需要去学习多种 API(JAXP 和 XQJ) 来运用 XML 标准。 Java 平台正逐渐变得更加应变，这也是业界对它的要求，因此基于业界的支持和用户的需求我期待着这些标准能够被吸纳进该平台。IBM 将会继续驱动 XML 的 Java 标准化过程，为用户创造价值。 如果 Java 平台的进展到可以处理 XPath 2.0，XSLT 2.0 以及 XQuery 1.0，我们的实现仍可以保留。目前 IBM 的 JVM 也是用的自己的 XPath 1.0 和 XSLT 1.0 实现。IBM 有这样的历史，在支持 Java 标准的同时，JVM 的 XML 部分还提供高效的，可靠的，功能性的附加值。这些改进将会持续为整个 WebSphere 系列产品在 XML 处理，web 服务和 SOA 等方面提供有力支持。

更多关于 WebSphere XML 功能包的信息可以在 WebSphere 社区博客上找到。那里有初始指南，其中包括了安装指引，也可移步 YouTube观看。

查看英文原文： IBM Adds Support for XPath 2.0, XSLT 2.0 and XQuery 1.0 to WebSphere 7