级别： 中级 David Marston (David_Marston@us.ibm.com), 软件工程师, IBM
Joanne Tong (joannet@ca.ibm.com), 软件开发人员, IBM
2007 年 1 月 30 日 XSLT 2.0 包含一些允许从 1.0 样式表逐渐升级的特性。但是有些情况需要进行全面修订，以便能够重新检查和改进整个架构。应该全面修订还是采用渐进式的方法？本文提出了一些相关的设计问题来帮助您做出决定。本文还提供了一些关于组织特征（这些特征可能决定每种升级策略的成败）的指南。要阅读本系列的其他文章，请访问 准备升级 概述页面。
关于本系列教程
W3C 发布的最新规范 XSLT 2.0 是一种转换 XML 文档的语言。它包括很多新的特性，部分是为克服 XSLT 1.0 的不足而设计的。这组文章从 XSLT 1.0 用户的角度（希望解决老问题、学习新技术和发现值得期待的新特性），提供了对 XSLT 2.0 的高水平概述和深入剖析。我们提供了来自常见应用程序的例子，并为那些希望升级的用户提供了实用的建议。为了帮助您开始使用 XSLT 2.0，本文还提供了相应的迁移技术。
考虑 XSLT 升级的策略
您可能听说过 XSLT 2.0 基本兼容 1.0，并增加了很多新特性。您的 1.0 样式表也许只用到了 1.0 的一部分，可能将用到 2.0 特性集合更小的一部分。准备升级的时候，要把精力集中到您使用的旧特性和吸引您 的新特性上。本文提出了五种选择，代表五种经过提炼的升级观点（也许不能说五种升级观点，因为也包括不升级的选择）。选择哪种策略有两类决策因素需要考虑：组织的能力因素和吸引您的 2.0 特性的推动因素。
需要知道什么
XSLT 规范的 2.0 版引入了一个术语样式表模块来表示能够导入或包括到称为样式表的集合实体的单位（通常是文件）。模块提供了比模板划分更强的划分，主要因为 XSLT 声明通常局限于单个模块。阅读完本文并且考虑了哪种方法最好之后，如果准备采用渐进式的方法，可以使用模块把旧的 XSLT 代码从新代码中划分出来（除了已有的模块划分之外）。
为了便于从 1.0 样式表迁移到 2.0，厂商可以（根据自己的意愿）提供支持向后兼容（BC）的 2.0 处理程序。在样式表中，该特性由 version 属性控制，它可以出现在任何元素中。（还记得吗，在 1.0 中，version 属性只能出现在顶层 xsl:stylesheet 元素中。）如果一个元素包含该属性，并且值为 1.0，则对该元素本身及其中的子树启用 BC 特性。从概念上说类似于能够像在 1.0 中那样执行的代码孤岛，除了极少数例外情况。要记住，该特性是根据样式表的文档结构而不是运行转换时的执行流来启用的。比如，如果 xsl:call-template 指令包含属性 version="1.0"，但执行中调用的命名模板包含属性 version="2.0"，则执行那个被调用的模板时不会启用 BC。
类似的，被导入或者被包括的样式表模块如果包含属性 version="1.0"，则对那个模块启用 BC 特性，即使主样式表是 2.0 样式表也是如此。如果执行由 2.0 处理程序在 BC 模式下执行，结果可能和 1.0 处理程序生成的结果不完全一样。关于 1.0 处理程序和 2.0 处理程序 BC 模式的差异列表，请参阅 XSLT 2.0 (附录 J)、F&O (附录 D) 和 XPath 2.0 (附录 I) 的兼容性附录。（链接见参考资料中的 developerWorks Standards 清单。）
其他工具为 XSLT 1.0 和 XSLT 2.0 处理程序提供了不同的代码，但是它们在更低的层次上工作。这一节的概念对于准备升级的策略来说应该足够了。
选择适合您的策略
每种选择各有利弊。这一节简要描述各种选择，列举了各种优点和需要付出的代价。少数选项把“可以应用当地标准调整或者代码清理”作为一个优点，意思是说已有的代码清理项目列表仍然有用。清理可能是关于编码风格或策略（如关于哪些模块拥有包含特定声明的特权）的内部规定。
选项 1：完全按 2.0 重写
如果选择这种方式，那么就类似于一切从头开始。为了充分利用 XSLT 2.0 的语法和特性，必须为可能需要修改整个设计和重写大部分样式表模块作好准备。如果当前的样式表有很好的模块化结构，可以选择保留原来的结构。更常见的情况是，如果您的 1.0 样式表已经有清晰的架构，您就可以节省一些计划时间，这取决于您希望利用哪些 2.0 特性。
| 优点 | 缺点 |
|---|
- 因为基本上从零开始，所以可以充分利用 2.0 的语法和特性的优势。
- 不需要寻找支持向后兼容的 2.0 处理程序。
- 使用 2.0 特性可以让代码更容易阅读。更多信息请参阅本系列的第 1 部分。
- 因为不需要向后兼容，代码代码更简单直接。
- 结果是跨 2.0 处理程序的可移植性。
|
- 必须学习有关的所有 2.0 特性。（马上！）
- 马上面临着很多分析和准备工作要做。
- 等待得到回报的时间最长。
- 该设计很难继续使用 1.0 代码，必须中断开发工作。
|
选项 2：将大部分样式表转化成 2.0 但保留 1.0 孤岛
如果全部用 2.0 重写过于激进，那么次佳的选项就是将大部分样式表模块转换到 2.0 并重用一些 1.0 模块。可以在单个模板或者更深的层次上保留 1.0 孤岛。该选项仍然需要一些规划，特别是在什么地方使用新的 2.0 特性，并调查在新的样式表结构中旧模块的可重用性。
| 优点 | 缺点 |
|---|
- 如果希望最终避免使用 BC 的话，该选项是渐进式迁移的最佳方法。
- 该选项可以将注意力集中到向后兼容和喜欢的特性上。
- 可以增强代码的可读性。改进可读性的例子请参阅本系列的 第 1 部分。
- 可以增强代码的模块化和可重用性。
- 可以像过去那样应用本地标准调整或代码清理。
|
- 本地版本控制和调整中容易出错。
- 该选项需要支持向后兼容的处理程序。
- 和孤岛有关的代码可能更难懂（虽然其他地方改进了）。
- 马上需要很多规划工作以便切实地改进代码。
- 如果避免触及薄弱的部分，这种方法可能延长混合使用多种版本的时间。
- 选择不同版本的分支代码可能需要更多的编码时间。
|
选项 3：建立 2.0 孤岛或者重写需要全面修订的模块
如果需要特定的 2.0 特性，可以尝试在 1.0 样式表中补上 2.0 版的孤岛，使用支持向后兼容的 2.0 处理程序运行它。如果处理程序生成意料之外的结果，则调整 1.0 模块直到满意为止。该选项把目标集中到需要的 2.0 特性上，规划和重新设计的工作量很小。自然，如果需要的新特性很容易隔离出来，那么这种方法最有效。关于哪些特性更有可能隔离出来的一些思路，请参阅后面的 收缩选择的余地 一节。
| 优点 | 缺点 |
|---|
- 可逐步进行修改，是否进行修改由特殊的需求或者某一特定增强是否能带来很大好处来决定。
- 可以逐步学习新特性。
- 可以把精力集中到性能瓶颈上。
- 可以集中提高模块化和可重用性。
- 如果必须保持和纯 1.0 处理程序的兼容性，这种方法更容易。
- 可以像过去那样应用本地标准调整和代码清理。
|
- 选择该选项通常会减缓采用新的 2.0 特性的进度，也不能很快享受到相应的好处。
- 这种打补丁的方法可能由于使用错误的版本而造成错误。
- 该选项需要支持向后兼容的处理程序。
- 使用孤岛可能损害整体的可读性（虽然孤岛本身可能改进了）。
- 确定需要修改的地方时可能很难预测孤岛的数量和分布。
- 更难利用具有广泛影响的新特性，如模式感知。
- 支持 BC 的 2.0 处理器运行 1.0 代码仍然面临同样的问题，调试的时候需要了解两个版本。
|
选项 4：将样式表的版本改为 2.0 然后调试
如果需要将已有的 1.0 样式表快速转化成 2.0 样式表，为何不将样式表版本属性设置为 2.0 看看能否从 2.0 处理得到预期结果呢？如果不成功，就开始调试，逆向跟踪每个模板的结果并进行修改直到满意为止。调整可能涉及到使用适当的 2.0 指令，或者（如果支持 BC 特性）将版本属性设为 1.0 看看会发生什么。当然，该选项不太关心利用新的 2.0 特性。
| 优点 | 缺点 |
|---|
- 可以采用渐进式方法进行转换。
- 如果 1.0 样式表没有出现兼容性异常，那么这种转换方法可能最快。好的测试集可以保证成功转化。
- 如果幸运的话，不需要寻找支持向后兼容的 2.0 处理程序。
- 该选项很容易起步，开始的时候不需要费多少脑筋，因为不需要计划，也不需要知道需要使用什么新特性。
- 该选项可以将注意力集中到向后兼容和喜欢的特性上。
- 可以像过去那样应用本地标准调整和代码清理。
|
- 如果出现问题时选择将版本设置为 1.0，该选项需要支持向后兼容的处理程序。
- 本地版本控制和调整中很容易出现错误，因而延长了调试周期。
- 由于向后兼容和调整，得到的样式表可能很难读懂。
- 没有启动计划，更难利用具有广泛影响的新特性，如模式感知。
- 很难预料转化需要多长时间。采用这种危机驱动的方法，一开始的 bug 列表可能很长。
|
选项 5：继续使用 1.0
您可能会问，既然 1.0 样式表工作得很好，那么何必改变呢？不需要学习 2.0 语法，不需要规划 2.0 样式表结构，也不需要安装 2.0 处理程序。对于您也许可行，但是要记住 2.0 能够完成 1.0 处理程序根本做不到的事情，而且 2.0 克服了 1.0 的很多不足之处。
| 优点 | 缺点 |
|---|
- 什么也不用做，也不需要新的处理程序（直到您再也雇不到人来编写纯 1.0 代码）。
- 不需要阅读六个新规范。
- 如果您正在使用开放源代码产品，尤其是具有内部编写的扩展的开源产品，并且您对这种能够访问源代码的情况感到满意，那么您可以继续保持这种满足感。
- 1.0 处理程序已经成熟，经过仔细的调试。
|
- 不能利用新的 2.0 特性（请参阅 第 1 部分）。
- 处理程序 bug 修正的周期可能延长，因为 XSLT 产品开发人员可能不会再 1.0 上花费更多时间。
- 随着时间的变化，知道存在一种可读性更强的 2.0 替代品，XSLT 1.0 中的老技术可能变得更加面目可憎。
|
混合各种选项
前面的选项有意用单纯的观点阐述，可以混合使用这些方法来适应您的需要。比方说，可以采用选项 1 和 2 的方法制定宏大的计划，但采用选项 4 试试看的办法来实施。如果不喜欢当前的样式表模块化，可能希望从功能出发重构所有的模块，然后进一步重构打破使用指定 XSLT 版本的模块，就像选项 2 和 3 那样。另一种可能是选择一个诱人的特性，如样式表函数（更多信息请参阅本系列的第 1 部分），确定能够使用它的所有地方，然后决定是否将这些部分隔离出来（选项 3）或者彻底重构（选项 1）。
XQuery 怎么样？
如果目标是从数据存储中提取数据，然后以带标签或者格式化的形式呈现数据，不需要大量改变结构，那么您可能会发现 XQuery 能够满足这些需要。其他 developerWorks 文章（请参阅 参考资料）讨论了 XQuery 1.0 并和 XSLT 作了比较。
做决定之前问问自己这些问题
除了把您推向某个选项的技术因素以外，还要考虑企业文化的因素。
为什么这么做？
升级到 2.0 常常是因为受到 1.0 中所没有的那些 2.0 特性的吸引。这是您准备把样式表升级到 2.0 的原因吗？如果是，那么最吸引您的是什么 2.0 特性？哪些好的新特性需要在时机成熟的时候部署？
企业如何管理开发？
企业文化在规划方面做得怎么样？企业能够承受多大的风险？有没有人善于浏览整个代码库，发现普遍的问题和机会？更喜欢代价低的调整和删改还是第一次就把事情做好（但是代价高）？有没有维护（bug 修正）的资源？bug 修正是主动进行的吗，过去的效果如何？
资源在哪个阶段是可用的？
您有多少时间来学习新规范？做迁移计划呢？重新设计样式表结构呢？相对而言，又有多少时间重新编写样式表模块？部署需要的 2.0 特性是否有时间要求？如果不能承受全部升级的成本，那么企业选择渐进式的迁移（如选项 3）还是采用快速修正的办法？
全部重写对企业来说是否负担太重？
选项 1，即使用 2.0 全部重写，对您的企业而言是否过于冒进？另一方面，是否有架构师要求层次清晰的样式表设计？如果不能采用其他选项是否这是唯一的办法？如果希望进行层次清晰的设计，可以把 2.0 的扩展特性集一并考虑进来。
关心跨 XSLT 处理程序的互操作性吗？
事先要确定样式表是否能用于多种处理程序，比如来自不同的厂商、在不同的平台上、甚至遵循不同 XSLT 版本的处理程序。
能找到支持向后兼容的 2.0 处理程序吗？
如果在您的操作环境中不能使用支持 BC 的 2.0 处理程序，就不能选择选项 2 和 3。此外，选项 4 也会受到更多限制，因为所有的 bug 修正都必须使用 2.0 的方法。
限制选择的余地
上一节列出了每种方法的优缺点，供您权衡。下面的提示可能有助于排除一些选项。要采用这些快速排除法，需要知道最希望使用 2.0 中哪些具体的特性：
- 如果没有支持向后兼容的 2.0 处理程序，就必须采用选项 1、5 或者选项 4 的一个子集，所有的 bug 修正必须采用 2.0 方式。
- 如果对模式感知、新的数据类型、选择整理、增强的类型匹配（XPath 2.0 的 2.5.4 节，请参阅参考资料）或者操作名称空间前缀有兴趣，则首选选项 1 或者考虑选项 2。这是那些影响范围最广的特性。
- 如果对频道参数、样式表函数、XPath 中的 forExpr（FLWOR 的一个子集）、next-match 或者模式（mode）的改进感兴趣，首选选项 1 和 2，选项 3 可能也够了。在整个代码库中寻找使用这些特性的机会是不错的做法，但这不是必需的。
- 如果对 ifExpr、rangeExpr、正则表达式函数和指令、临时树的改进、更好地控制输出字符或者多重结果文档感兴趣，选项 3 可能就够了。这些特性的影响范围通常比较小。本系列的第 1 部分讨论了后面的三种特性。
- 如果样式表比较小或简单，作为一种快速修改方法选项 4 可能就够了。
- 如果主要希望使用分组、序列、限定表达式（请参阅参考资料中 XPath 2.0 第 3.9 节的链接）或者指定一个命名模板作为启动模板的选项，单凭这些不能说明哪种选项更好。选项 1、2 和 3 都有可能，但需要进一步分析对样式表的影响范围是大是小。
结束语
回答了对企业的评估问题并审视 2.0 特性之后，可利用本文提出的决策因素制定升级的初步计划。当然，这只是高层次的战略分析，随着计划的深入还要重新审查这些问题。
参考资料 学习
获得产品和技术
- IBM 试用软件：用这些试用软件开发您的下一个项目，这些软件可以直接从 developerWorks 下载。
讨论
作者简介  | | | David Marston 从 1998 年后期开始使用 XML 技术，尤其关注标准的符合性问题。在超过 25 年的计算机从业经历中，他参与了软件开发的各个方面。他毕业于达特茅斯大学，是 ACM 成员。他参加了 IBM Research 的 Next-Generation Web 团队。可以通过 David_Marston@us.ibm.com 和他联系。 |
| | | Joanne Tong 是一位开发人员，在 IBM 多伦多实验室开发 IBM 的 XSLT 处理程序。她目前是 W3C XSLT 2.0 和 XQuery 1.0 Serialization 规范的编辑，XSL 工作组的一位活跃成员。可以通过 joannet@ca.ibm.com 和她联系。 |
对本文的评价
| 
