XSLT:XSL 转换(XSL Transformations)“这么多规范?”有这种想法的人不只您一个, 难以理解为何 W3C Query Working Group 搞了这么多互相关联的文档。
如果说是因为复杂,那么我无法反对,但我确实奇怪为何 XSLT1.0(参见 参考资料)能够用一个规范(或者说两个 — 因为还有一个相关的 XPath 1.0 规范)就能办到。
在 XQuery 1.0 规范的定义过程中,一直有几个问题始终跟着 XQuery。
其中很多提出的极其严重的限制使(当时的)我确信必将阻碍 XQuery 的发展(经过一年紧锣密鼓的开发,大部分最终证明是无关紧要的)。
承认自己的错误是一种好的学习方法,因此我认为可以重新看看这些问题。
永恒的话题 1:XSLT 与 XQuery作为一名活跃的 XSLT 程序员,我非常关心这两种技术的交叉之处。
XSLT 和 XQuery 的语法虽然不同,但在很多方面相同 — 比如,这两种语言: 都输入 XML,输出 XML 具有相同的数据模型和类型系统 都是声明性的,即没有副作用 都使用 XPath,具有相同的内置函数库XQuery 语法这几个例子说明了 XQuery 语法的几个恼人之处: XQuery 经常使用花括号(),而 XSLT 仅在属性值模板(Attribute Value Template,AVT)中使用。
负号(-)需要增加空格。
比如 t-1 是一个合法的变量名,应该写作 t - 1。
XQuery 中的代码注释(: : )让我感到好笑,但我发现再定义一种新方式注释源代码也没有多少必要。
XSLT 和 XQuery 当然也有明显的区别,(从 XSLT 爱好者的立场上)也可以说 XQuery代表 XSLT 2.0 的一个功能子集。
比如,XQuery 没有动态邦定的概念,而 XSLT 通过模板匹配规则提供了动态匹配。
XSLT 还提供了某种形式的多态,即使用 xsl:import 覆盖模板匹配规则。
XQuery 没有这样的设施。
用过 XQuery 之后,我发现有些工作更适合用 XSLT,有的则更适合用 XQuery: 毫无疑问,XQuery 非常适合查询 XML。
我发现,它非常适合提取小段数据,然后 交给 XSLT 格式化和表示。
XQuery 适合控制处理(比如 XSLT),特别是在 XML 数据库中。
需要格式化数字的时候 XSLT 就胜出了。
XQuery 更容易理解,学习曲线也相对平缓。
在 XQuery 中遍历树非常麻烦。
使用 XSLT 模板匹配更合适。
学习 XSLT 和学习 XQueryDan McCreary 写的一篇博客文章(Opinion, , 2008 年 6 月) 讨论了为什么有经验的 SQL开发人员可能会发现 XQuery 比 XSLT 更容易学。
无疑向数据库管理员(DBA)推销 XQuery 要容易得多,十年来他们一直在抱怨 XML 对自己的系统的入侵,抱怨为什么要把 XML 分解并放到他们的关系表中。
注意:关于 XQuery 和 XSLT 更全面的比较,建议您阅读 Benoit Marchal 的文章“Comparing XSLT 2.0 and XQuery”(见 参考资料)。
永恒的话题 2: XML Schema 和数据类型W3C XQuery Working Group 在 XQuery 中引入 XML Schema 数据类型(见 参考资料)引起了极大争议,由于后者未能让整个 XML 社区接受为约束和验证 XML 的最佳方法,这种依赖关系被人们认为颇具讽刺意味。
后来令我吃惊的是,如果不需要就不用去管数据类型,总体而言 XQuery 实现在这一点做得很好。
我不想再重复关于 XML Schema(见 参考资料)或其他模式语言优劣的争论。
可维护性和快速重构等因素可以帮助您决定 XQuery 应用程序中是否使用模式或数据类型。
下面是我遵循的几条非正式的原则: 如果不使用模式,则在函数签名中使用基本数据类型。
如果使用 XML Schema 和数据类型,应考虑自动生成代码(存根代码等)以方便 维护。
通常可以忽略模式和数据类型,等到以后再加上,虽然可能损失一些好处(捕捉错 误)。
第一次使用 XQuery 的时候我建议采用这种办法。
此外,如果不喜欢固定到某种特定的模式技术,在 XQuery 中完全可以不去管它。
永恒的话题 3:强类型与弱类型静态类型还是动态类型是各种程序员社区都常见的永恒话题。
XQuery 只不过是这场旷日持久而有时候无足轻重的争论的另一个(不情愿的)牺牲品罢了。
上一节中曾经提到,XQuery 加入了 XML Schema 数据类型。
在 XQuery 中可以完全忽略它,就是说强弱或者静态动态类型的争论实际上根本没有必要:两种方法都是有效的,用