使用tDOM和tDOM XSLT

2002-8-28 13:56:20【来源】

使用tDOM和tDOM XSLT

--高性能的、用Tcl脚本编制的XSLT引擎


Cameron Laird(Cameron@Lairds.com

副总裁,Phaseit, Inc.

2002 年 2 月

tDOM 是一种高性能的、用 C 编码的、面向 DOM 的 XML 处理器。tDOM XSLT 是用 tDOM 构建的在简单测试中具有极其优良性能的 XSLT 引擎。tDOM 和 tDOM XSLT 是开放源码项目,几个组织已将它们用于关键任务的生产中。本文解释了要利用它们的优点,您需要知道什么。
简单的基准测试显示,tDOM 是目前可用的运行最佳的 XML 处理器之一。通过使用 Tcl“脚本编制”语言,可以产生特别高效的开发环境 — 在开发和执行中都很快。一个“并列”(或者两种语言)的开发模型将 Tcl 和 XSLT 的优点结合起来用于 XML 操作的不同方面。

tDOM 特征

tDOM 是一种与 Tcl 语言绑定的开放源码,用 C 编码的、面向 DOM 的 XML 处理器,由 Jochen Loewer 创建并维护。tDOM 结合了 James Clark 的 expat 的一个版本,该版本目前基于 SourceForge 发行版 1.95.1。expat 以其质量和性能而著称。最新的发行版支持 DOM 级别 2。(在参考资料中有对 tDOM 的评论和相关信息。)

已经有几个商业产品依靠 tDOM,包括这些示例:

Ideogramic ApS 在其面向对象的 CASE 工具中使用 tDOM 来解析和生成“XML 元数据交换(XMI)”文档。

BMEcat,正如在其主页中描述的,是“德语国家中电子产品目录使用最广泛的(XML)交换标准”;tDOM 是独立咨询师 RolfAde 开发来管理和编辑 BMEcat 数据的工具的基础。

工程师 Zoran Vasiljevic 将 tDOM 构建到 AOLserver 以获得高性能的、基于 DOM 的 HTML 生成。

其它应用程序包括复杂产品的配置和移动数据交付。

用 tDOM 编程

有几个优点推动 Loewer 实现 tDOM。它有灵活的面向对象的语法。它的运行速度非常快,对于涉及企业级的目录编制和采购工作的大型 XML 文档,这是一个特别的优点。它还非常节约地使用内存,并且它自称已经有便利的且功能强大的 XPath 实现。下面是对这些优点的定量测量。

很容易启动 tDOM,特别是在 UNIX 主机上。虽然目前源码下载(请参阅参考资料)包括 Mingw32 和 Visual C++ 的 Makefile,Loewer 却没有积极地维护后者。他确实在下载页上提供了 Mingw32 版的 Tcl8.2 用的 tdom0.4.dll。

对于 UNIX,生成和安装都很常规。根目录中的 README 指引您执行 cd unix; ./configure; make; make install,在我尝试过的大多数系统上它们都能顺利完成。安装 Tcl 二进制文件是不够的:tDOM 生成还期望使用 Tcl 源码。使用 gcc 而不是 Tru64 UNIX 上绑定的编译器使我稍微容易地得到了结果。您可能愿意用 ./configure --enable-gcc 来替代上面序列中的 ./configure。

一旦安装完 tDOM,要从 Tcl 上使用它是最简单的。可以从类似如下的简单示例开始:

domBench.tcl
      #!/usr/local/bin/tclsh

       package require tdom
       cd tests
       source test.tcl

 虽然 tDOM 源码发行版中包含的 docs 目录内容很简洁,但它非常精确。熟悉 XML 概念的程序员只需花很短的时间就可以开始使用 tDOM 有效地进行编码。

tDOM 节省时间和空间

Rolf Ade 已经完成了 tDOM 最广泛的基准测试,这是在“Java XML 表示基准”(XMLbench)的框架内进行的。XMLbench“完整下载”包括下列随时可运行的 .jar:

Crimson v1.1
Xerces v1.2.0
JDOM b6
dom4j v0.2
Electric XML v1.4

“完整下载”还有一个包括小的 DOS 批处理文件来迭代测试的小基准测试框架,以及三个示例 XML 实例:

much_ado.xml(202029 个字节;莎士比亚剧本的 XML 标记)

periodic_table.xml(116505 个字节;元素的基本化学数据)

xml.xml(162471 个字节;正式 XML“建议书”的 XML 版本)

Ade 还在这其中补充了他自己的 run.sh 来将测试移植到 Linux 中:

run.sh
      #! /bin/bash
       java -Xms128M -Xmx128M -cp \
         lib/xmlbm.jar:lib/jaxp.jar:lib/xerces.jar:\
         lib/crimson.jar:lib/jdom.jar:lib/dom4j.jar:lib/EXML.jar \
         com.sosnoski.xmlbench.XMLBench $1 $2 $3 $4 $5 $6

 Ade 在他的试验中使用两台主机:

Linux 2.2.13,奔腾 II 333MHz,384 MB 内存,运行 Java 版本 1.3.0 Classic VM 1.3.0(IBM 公司)

Win 2000 专业版,赛扬 466 MHz,192 MB 内存,运行 Java 版本 1.3.0rc1 Java HotSpot(TM) ClientVM 1.3.0rc1-S(Sun Microsystems Inc.)

在 Linux 上他使用 tDOM-0.62-2905,在 Win 2000 上他使用 tDOM-0.61,这两个都是临时发行版。他将用 Java 编码的基准测试代码转换成这个小的 Tcl 程序:

domBench.tcl
        proc SAXtest {xmlstring count} {
             set parser [expat]
             puts "Parsed document text in [time {time {
                 $parser parse $xmlstring
                 $parser reset} $count}]"
         }
        
         proc DOMbuild {xmlstring count} {
             puts "Build from parse in [time {time {
                 set doc [dom parse $xmlstring]
                 $doc delete} [expr $count - 1]
                 set doc [dom parse $xmlstring]}]"
             return $doc
         }
        
         proc runTest {filename count} {
             set fd [open $filename]
             set xmlstring [read $fd]
             close $fd
        
             SAXtest $xmlstring $count
             set doc [DOMbuild $xmlstring $count]
         }

Ade 注意到,在与 Java 的速度比较中,SAX 稍胜一筹,因为 XMLbench 实现代码包含一个简单的事件处理程序。由于他感兴趣的是独立地进行 SAX 解析,所以他没有为 tDOM SAX 测试编写相应的事件处理程序。测试已经显示这使 Java 应用程序的速度只降低了“一点点”。

何时使用 tDOM

最终结果如何呢?Ade 总结到:“在 Linux 下,tDOM SAX 比 Java 快 4 倍,在 Windows 下快 3 倍。在这两种平台中,tDOM DOM 比最快的 Java 解决方案还快了约 4 倍。”内存测试证实了 Ade 自己在超过 18 个月的商业使用 DOM 的丰富经历:“tDOM DOM 树通常需要的内存是 XML 文件大小的 2 和 3.5 倍之间...”在商业使用中绑定到 C 和 Java 的通用 DOM 解析引擎常常需要基本文档中使用的内存的 5 倍到 30(!)倍。

这并不意味着 tDOM 应用程序都是可比的基于 Java 的应用程序的速度的三倍。DOM 树的解释型访问,正如目前用 Tcl 实现 tDOM 那样,大大降低了处理速度。由于大型 XML 编辑器占用一定的解析时间而内存消耗可能是关键的,因此纯粹基于性能考虑,大型 XML 编辑器是 tDOM 的自然选择。

然而,即使要求速度相对缓慢的用 Tcl 编码的 characterdata 编程项目也正逐渐选择 tDOM。其 XPath 能力是出奇的方便。它还向内存中的 DOM 创建、面向流的 SAX 处理、DTD 验证、对 XPointer 和其它 XML“附件”的部分支持以及可能是最重要的 tDOM XSLT 提供快速、便利的命令。

那些要求最佳性能的开发人员应考虑使用 tDOM,因为最近的发行版包含一个特殊的“高级解析程序”。独立顾问和经常性的公开源码的志愿者 Richard Hipp 在 tDOM 中添加了一个流线式的解析器。以不需要外部实体而编码七位 ASCII 或 ISO-8859-1 而著称的文档可以请求 tDOM 的 -simple 解析器。这使构建 DOM 树的速度是基于 expat 的常规 tDOM 速度的两倍 — 比基于 Java 的引擎快了一个数量级!

tDOM 在测试发行版中只支持 DOM 2

如果您对完整的 DOM 2 能力有特殊需要,但是 tDOM 在 0.7 以前的发行版可能不适合您。只有计划在 2002 年 2 月第一周期间首次发布的 0.7 发行版中,tDOM 才完全支持名称空间。较早的版本也不支持 Unicode 转换,因为 Loewer 和其他现有的 tDOM 的用户已适应了用相同的格式处理(外部的) XML 数据存储和(内部的) DOM 结构。而且,tDOM 较早的发行版不处理复杂的实体声明。

Loewer 从 2001 年夏天开始就一直在实现和测试 DOM 2 需要的方法,包括 setAttributeNS、getAttributeNS 等等。0.7 测试版废弃了 0.6 发行版吗?很明显没有;几乎没有例外,Loewer 的版本已向上兼容,并且我已经与当前 tDOM 用户交谈过,他们对 DOM 2 的能力几乎没有迫切的需求。请注意在较早的 developerWorks 的专栏文章:Programming XML and Web Services in TCL 中描述的,TclDOM 自 2000 年春季开始就已经支持 DOM 级别 2 了。看来,TclDOM 性能大约已下降到与其竞争的 Java 引擎范围内了。

tDOM XSLT

tDOM XSLT 是基于 tDOM 的新的 XSLT 实现。回顾 XSLT(XML 样式表转换)的定义,正如它的当前定义标准介绍的那样:它是一种函数型的“将 XML 文档转换为其它 XML 文档的语言”。

这里是大多数组织如何使用 XSLT:他们维护源码主文档,通常是 XML 中的文档。这些主文档很详尽并且形式一致 — 即,每个文档都应该包含关于一个主题的所有信息,包括语义内容、格式化标记以及与其它文档的关系。要用一种适合最终使用的格式来表示特殊的文档,XSLT 将 XML 主文档映射成一种特定语法。一个通常的示例是 HTML 的生成,它适合于根据相应的 XML 源码进行常规 Web 发布。

XSLT 是一种高级语言,它一般在常规的 XML 转换中非常有效。tDOM XSLT 的一个优点是它使开发人员有机会用 Tcl 编码 XPath XSLT 函数,正如 tDOM 为 DOM 编程所做的那样。这是使 XSLT 应用程序可扩展的一个简便方法。

如何使用 tDOM XSLT

当您生成和安装 tDOM 的发行版 0.63 或者更高版本时,tDOM XSLT 表现为一个固有的优点。tDOM XSLT 还在快速开发中。当准备使用它时,您最好与 Loewer 联系,向他要最新源码,因为他不总在公共区域中对内容修正。

发行版 0.63 还没有以帮助页的形式包含 tDOM XSLT 的文档。但是,源码发行版包含了 xslttest,它是示例的完整目录。正象正确使用 tDOM 时那样,开始学习 tDOM XSLT 的最方便的位置可能是通过包含的样本代码:

      #!/usr/local/bin/tclsh

       package require tdom
       cd tests
       source xslttest.tcl

 tDOM XSLT 的性能

通过在一个示例 XSL 规范(XSLTMark 的 prettyprint.xsl)上测试 tDOM XSLT,Loewer 跟踪了它的性能。在他的 600 MHz Linux 主机上,通过使用以 gcc -O3 编译的 tDOM XSLT,完成一个迭代需要大约 0.18 秒。XSLTMark 站点本身报告,在一台 500 MHz 主机上,完成每个迭代需要 0.3 到 16 秒。Microsoft XML 3.0 需要 0.45 秒,而 Oracle XSLT 2.0 需要 0.43 秒。用 Loewer 的话说,tDOM XSLT 还是“非常年青的”产品,并且还没有人进行过直接比较,这些测试表明 tDOM XSLT 是非常有竞争力的。

并列 XML 应用程序

tDOM XSLT 的性能和节省使用内存必定能引起那些正在使用其它 XSLT 引擎的读者注意。尽管 tDOM XSLT 还有其它优点。

tDOM XSLT 的一个好处是它支持“并列”设计。这是我在 Programming XML and Web Services in TCL 中介绍的一个主题。其想法是要编写 XSLT 应用程序的脚本 — 意思是,使用者可用 XSLT 为一个程序很方便地编写尽可能多的代码,接着使用 Tcl(或者是可类比的脚本编制语言)的小代码段来将 XSLT 代码段“粘贴”到外部接口中。XSLT 是一种非常好的函数型语言,它非常有效,很透明(或者甚至可证明的)并且倾向于使用域。Tcl 的表达性、易学性以及到包括数据库、图形用户界面(GUI)以及系统接口在内的“外部”资源的广泛连接有助于使这两种语言相互很好地合作。

考虑这一点:假设您的组织已经有一组相关的准确 XSLT 程序,例如它们能够根据发票自动生成支付请求。当然,这是 XSLT 的一个出色工作。但是,Tcl 是将应用程序连接到真实世界的数据源和接收器的一个极佳方法:

Tcl 善于从进入的电子邮件流中过滤掉附加的 XML 实例。

Tcl 可以插入需要对诸如轻量级目录访问协议(LDAP)那样的数据管理器进行认证的数据。

Tcl 能通过累积从 XSLT 代码中回调的结果来实现实时监控财务状况总结的 GUI 控制面板。

从管理的角度来看,XSLT 处理域知识。XSLT 获取有关投标、采购订单、发票等等工作流的组织性情报。Tcl 具有编程数据流的所有与计算机相关的职责。

许多其它语言也可以作为 XSLT 的“并列”的候选语言。特别是 Java,现在看起来已受到许多大型组织的垂青。tDOM 的有效性引起了热烈的争论;在与一些 Java DOM 引擎的比较中,其小巧的内存资源占用,却完全排除了当前许多 XML 项目面临的内存壁垒。Tcl 的简洁明了同样很好地与我建议的“粘贴”作用相匹配。粘贴不需要 Java 的声明和种类安全性所带来的编程负担。要这样做,比较好的方法是使用一种轻量级的语言,该语言可以智能地对其本身进行动态分类。

结束语

tDOM XSLT 是一个年轻的项目,它现在正进入到实际应用中,主要是在欧洲。另一个方面,它自称具有引人注目的性能,并且它的第一批用户已成功地经历了结合 XSLT 和 Tcl 的“并列”样式的早期试用。如果您想进行速度较快的 XSLT 应用程序的快速开发,那么 tDOM XSLT 值得引起您的注意。

参考资料

关于作者

作者的照片:Cameron LairdCameron Laird 是独立咨询公司
Phaseit, Inc. 的专职开发人员。他经常编写 XML 和其它技术主题。可以通过 Cameron@Lairds.com 与他联系。

本行业子站内容由畅享网(http://www.vsharing.com)进行维护,如需帮助,请致电:021-51096826-152 email:content@vsharing.com