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流的连接。
• XPath2.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