标记语言巨星访谈录--与James Clark同步

body{font:small verdana}

code,pre{font-family:courier}

pre {background-color:#e1e1e1}

与James Clark 同步

-- 标记语言巨星访谈录

原作：Uche Ogbuji, Fourthought, Inc 首席顾问日期：2002.7.17

James Clark在标记语言(markup languange)的领域里可能是最有成就的开发者。在他不平凡的SGML和XML生涯里，曾经参与标准的制订，就标记语言与传统代码的关系提出了非常重要的看法，更重要的是，他写了许多程序，这些程序促进了XML(以及从前的SGML)从抽象的设想世界到广为流行的转变。在本文中，Uche Ogbuji采访了James Clark，集中讨论了XML的实用开发以及现状和未来。作者同时也就这些话题发表了自己的见解。

2001年12月, James Clark被XML 2001大会委员会授予首座XML奖杯，这是为了表彰他对XML团体所做出的许多突出贡献，没有人对他的获奖资格表示质疑。如果你曾经使用标记语言作过什么事情的话，你可能已经使用过James Clark写的代码：

Jade, Clark的DSSSL处理器(相当于SGML的XSLT之类)，受益于Linux Documentation Project的Linux用户使用它。

Clark的sgmls是世界上最广泛使用的SGML解析器。

expat或XT(解析器和XSLT处理器)为许多开发者采用。事实上，由于在Python, Perl和Apache项目中被普遍采用， expat是使用最广泛的XML解析器之一。

值得注意的是，所有这些都是开放源代码的，而且在开放源码开始风行之前就这么做了。

Clark的获奖也是出于他最近所做出的贡献。2001年，他创立了TREX, 一种XML schema的替代语言，与RELAX语言结合后形成了RELAX NG。尽管有来自W3C官方的schema定义语言的竞争，RELAX NG仍然极为流行。

为表达他对XML前途的关注，获奖之后Clark就XML面临的5个技术上的挑战发表了演讲。在他的演讲里，突出谈到了困扰着许多开发者的技术问题，对可能会在发展之路上造成障碍的某些做法提出了警告。

这里就是Clark提出的XML面临的5个挑战：

要进步，还要保持XML的简洁(Make progress yet keep XML simple) XML的强大在于其简洁性所带来的多样性。这种强大特性定建立过程中有个危险的误区，就是在核心内加入许多的特殊功能，而不是放在分开的、高级的层面上。

不要忽视XML的基础(Don't neglect the foundations of XML 如今XML变得如此重要，人们应回到基本的出发点，巩固XML的基础。最好清理一下会导致不必要的复杂性的历史遗留问题(例如某些很少用到的SGML特性)。另外，重要的说明比如Infoset(XML文档内信息节点的正规模型)应当建立在基础层面上。

控制处理管道(Control the processing pipeline) XML的标准化中所忽视的一个重要方面，就是应有一个定义完好(well-defined)的机制，对操作XML文档的处理管道(pipeline of processing)做出描述。由于现有的处理工具和方法多种多样，这一点显得尤为重要。

改进XML的处理模式(Improve XML processing models) 目前，开发人员通常都受困于DOM的效率低下和SAX的陌生感觉。需要有能够综合两者之长处的API。

避免不成熟的标准化(Avoid premature standardization) XML的成功使人们急于试图把所有与之相关的技术标准固定下来。为了不对以后的进步造成伤害，在标准确立之前，其中许多技术要经过更多的斟酌和实践。

本文基于我就这些技术挑战对James Clark的访谈。其中有问有答，有时还有我本人的解释和分析，读者一定对XML相当熟悉，对XML的各种处理技术应该也不会感到陌生。

基础问题：XML的核心

问：就像你在讲话中所建议的，你认为在“从背后给他一刀”之前，我们应从SGML学到哪些东西？

答：最重要的东西就是底层应当只关心句法，在语义上保持中立。

XML经常给开发人员留下这样的错误印象：它能自动为其结构化的信息提供意义，这就经常诱使人们把这种智能建在XML的底层。Clark提倡最底层应当只与句法打交道：一个处理器应当如何像其它处理器一样，对一个XML文档做出相同的理解，而更加智能化的特性应放在这层的上面层次内。

问：你对开发当中的XML1.1工作草案中提到的某些东西是怎么看的？

答：我认为字符实体(character entity)是个不大却倍受瞩目的问题，如果愿意的话是可以解决的。W3C XML Schema 的那些人(我和他们的看法经常有分歧)也想看到这个问题得到解决。

XML对字符的表达和处理很复杂，这令开发人员感到有些意外和无奈，并在XML团体中引起了无休止的争论。针对这个问题的专用工具，比如Simon St. Laurent的 Gorille，突出了它的重要性。关于在XML的1.1版中应增加或修正哪些内容，一直有许多议论，因为实际上在最新的XML Blueberry 草案中才刚开始对这点做出说明。

问：Tim Bray 已经把 XML-SW(XML Skunkworks)作为非官方草案予以公布。这似乎与你对XML1.1的建议不谋而合。你对这个计划有什么评论或想法？

答：我认为这是概念的一个很好验证。我认为它表明了XML1.0/XML Namespaces/XML Infoset/XML Base可以进行整合，而无需花费过多的工作量，这种整合的结果在某些方面比我们今天所拥有的更为一致和协调。但愿W3C所追求的也是如此。

问：你认为XSLT要具备哪些类型安全？

答：我认为不可能将静态的类型安全(static type-safety)嫁接到XSLT(或其它)上面，这只是事后诸葛亮。如果你想要一种具备静态类型检查的语言，就必须从一开始就对此进行设计：它对语言设计的影响非常大。我认为像XSLT这类的语言和其他更为“强类型”的XML处理语言都有其生存空间。我预测XQuery将会是后者的一个重要例子。

作为XSLT1.0标准的编辑，Clark在讲话中提到XSLT需要类型安全。与类型有关的问题在XSLT开发人员中相当普遍，最普通和明显的就是这种用法

<xsl:value-of select="spam"/>

而开发人员真正想要的是这样

<xsl:value-of select="'spam'"/>

这种情况下，我们本意是想用字符串，而实际却是节点集，要对结果进行除错往往非常困难。W3C规划中的XML XQuery语言是W3C标准系列(还包括XML Schema, XPath 2.0, XSLT 2.0)当中的一员，在这里类型特性正在被添加到XML。有趣的是，Clark在他的讲话中对过早的标准化提出过警告，而类型正是其中的一个方面。

问：你论述了需要有设计良好的XML API。你认为在基于开放源代码的API中有适合于效仿的吗？

答：有个以Java写的开放源代码的XML Pull Parser。我认为有可能做得比这个和微软的.NET中的XML API

更好。有几个开放源代码的Java数据绑定平台。不过，我认为这些东西才真正应当作为Java平台标准的一部分，就像Java API for XML Processing(JAXP)一样。现在已经有了一个关于 pull XML parser的Java Specification Request。

DOM为每个XML节点建立一个数据对象，它的内存开销很大，但对多数开发人员来说容易使用：你可以用许多主流编程语言中普遍采用的方式来访问对象的属性。SAX根据XML的构建过程返回一个自由的事件流，除了正在处理的当前节点外，它并不要求数据放在内存中。这样做效率较高，但是要求开发者掌握许多复杂的状态管理技术。一个pull API有个与DOM相似的接口(出于简单性)，而又足够聪明，只将当前处理过程中所需的节点装入内存，保留了一部分SAX的效率。

问：在你看来，是否有什么工作组、项目甚至产品能够为处理管道(processing pipeline)提供些有益的参照？你是否正在做这类尝试工作？

答：Sun的"XML Pipeline Definition Languange"(已提交为W3C的Note)看起来有意思，我认为它目前还不很理想。特别是那个非常基本的processdef元素，从安全性和可移植性(interoperability)的角度来看还很成问题。ISO的DSDL也为处理管道问题提供了思路。

模糊地带：普通问题

问：你提到XML是非常多样性的，而且它的优势之一就是可以表示多种信息。你是SGML界的老手了，有没有一些XML的应用特别出乎你的意外(或关注)的？

答：我对XML在RPC中使用得如此之多(像SOAP一样)感到非常惊奇。

问：在你工作过的所有软件项目中，你认为哪个是最重要的？你以什么标准挑选都行，但有一条：哪个项目对于一个重要标准的帮助理解、影响或者普通的实现最为重要？

答：问题有点难。我想我会选择sgmls。这是我做过的一个主要项目，它不是从头开始的，而是基于Charles Goldfarb的ARCSGML。sgmls把ARCSGML变成了一个可靠的、高质量开放源代码的SGML解析器。我认为它对扩大SGML的队伍非常重要，而且如果没有SGML队伍，就不会有XML的出现。

XML的未来

在一个成熟的团队的推动下，XML无疑正接近于从原始洪荒到成熟技术的转变。在这个转变中，它将会利用这个团队的所有经验和智慧，能够确保这项技术的长久生命力，并对开发人员真正有用。James Clark的经验和洞察力会有助于引导这个进程。请留意这里所探讨的许多进展，在不远的将来它们一定会改变你使用XML的方式。