XML 的发展已将近十年，至于更确切的数字要看您怎么计算了。W3C Recommendation Extensible Markup Language (XML) 1.0 在 1998 年 2 月 10 日发布，针对 XML 的工作则在 1996 年左右就已开始，而它根生于 SGML 也已经有将近 30 年的历史了。
引领 XML 发展的设计原理发布于 1996 年 8 月 25 日。第一个工作草案发布于 1996 年 9 月 14 日，当时定义的文档和今天您所看到的 XML 大部分文档非常相似。第一个草案和最终的推荐版之间的很多变动大都集中在标准中的一些比较模糊的地方。在 1996 年的时候，标签形式的平衡、分级的标记以及明确定义的文本编码都已经有很好的定义，所以 IBM Systems Journal 认为 2006 年是 XML 发展的第十年。不管您是否同意他们的计算，此专刊都确实值得所有的 XML 专业人员仔细阅读一遍，它包含了对 XML 有趣的回顾和一些非常有用的文章，这些文章对 XML 特定的技术和开发问题进行了讨论，还探讨了这项技术的未来发展以及相应的该领域的职业发展的大略情况。在本文中，我将就 IBM Systems Journal 中的一些文章进行评论和详述，重点放在其主旨文章 “Technical context and cultural consequences of XML” 和所包含的论文中的一篇 “Emerging patterns in the use of XML for information modeling in vertical industries”。后面的这个论文涉及了Thinking XML专栏的一个常见的主题 —— 特定于行业的 XML 词汇表的开发和采用。避免灭亡的历史
Santayana 一句古老的谚语 “忘记过去必定会重蹈覆辙” 放到技术领域不妨这样推断：“忘记轮子是怎么发明的人只能再重头做起”。为了学习如何最大限度从 XML 中受益，了解它的基本动机和指导原理是非常重要的。IBM Systems Journal 特刊中的主旨文章提到了其中一个最重要的部分：
SGML 的最初动机(并延续到了随后的 XML 中)就是保证处理文件中的内容或数据的应用程序被废弃或不可用后，这些内容或数据仍能长久存在;这样在文件内容中就不会嵌入处理或过程信息，相反，内容会被编码为条理清晰的文本，在每个地方都可以使用。
这也许是 XML 最基础的原理，有一个简单的故事说明了为什么这一点如此重要。在程序设计领域毫不犹豫地放弃使用 COBOL 语言随后的几十年中，COBOL 还一直作为一种必不可少的技能为一些招聘人员所追寻。在 20 世纪 90 年代，计算机科学课程中大量削减了 COBOL 的课程，大部分专业人员开始转向使用 C++、Java、SQL 等语言。然而，某些领域仍然坚持对 COBOL 技能的要求，一些行业因为这方面的需求很难满足而面临危机。引起危机的原因是很多关键的业务信息仍然受困于 COBOL 陈旧的程序，其陈旧可以追溯到企业第一次在信息系统方面做重大投资的时期。想要将 COBOL 数据转换成更先进的格式(例如关系数据库)非常困难，许多失败了的项目都证明了这一点。其中部分原因是数据量过大，而且这方面的人才也很难找。随着 2000 年的迫近，关于未将 “99” 到 “00” 的翻转考虑进去的 COBOL 和其他一些遗留系统中的数据将会造成严重后果的警告之声迭起。很多评论家将这段时期看作是对资源的巨大浪费，他们认为为过去的资源苦恼还不如积极地开发新的产品。造成这一切的根本原因就是这几十年来数据编码全都面向一种程序语言和处理系统：COBOL。对于要让数据超前当时的主流处理技术这一点并没有给予任何考虑。
这个沉重的教训以及很多类似的例子告诉我们，对数据进行开发非常有价值，这样数据可以比目前操作它的应用程序存在的时间更长。正确使用 XML 可以帮助避免产生诸如 20 世纪 90 年代爆发的这种人为造成的 COBOL 危机，它甚至可以做得更好，它可以通过在竞争压力下不断寻求新的应用程序来推动生产力的发展而不是成为发展的绊脚石。Charles Goldfarb 本人在 “The Roots of SGML -- A Personal Recollection” 一文(该文追溯了他所倡导的结构化标记语言，详见参考资料)中曾这样说过：
历史上，电子手稿包含控制代码或者宏指令，导致文档必须以特定方式格式化( “特定编码”)。相比较之下，20 世纪 60 年代末期出现的通用编码则使用了描述性标记(例如，“heading”，而不是 “format-17”)。
通用编码是 XML 及相关技术的基础。使用 XML 最重要的一个原则是 “如果 XML 某方面设计得与应用程序太过紧密，就可以认为这是一种 bug”。“Design Principles for XML”这篇简短的文档非常有用，您从中可以得到更多这方面的指导。
颇有收获的争议
XML 的成功源于它集合了大量不同的背景和利益，同样这也是很多冲突的起源。XML 的世界总是会有很多派系之间的竞争;据我观察，这种竞争要比您所见到的其他技术领域还要多。XML 的方方面面都经历过激烈的争辩，但这在实际的应用程序中并不会造成很深的分歧，在很多情况下，技术上不同派系之间的斗争所获得的利益远远超越了商业竞争所能带来的好处。通常供应商总是希望把自己的方案写到标准中去这样可以提高其产品在市场上的畅销度。当然，XML 的确也存在大量这样的情况，很多基本的原理性分歧也不断威胁着 XML 领域，试图把它分解成很多小团体。我引用了的 IBM Systems Journal 主旨文章也提到了这一事实：
XML 发展历程中其中一个最引人注目的方面就是来自不同阵营的团体之间密切协作，每一个团体对于该以何为重都有自己的看法，并会时常忽视来自其他团体的要求，这种冲突可能会破坏整个体验，但是持久性战胜了它。不考虑那些细微但持续不断的诽谤之声，这些团体已意识到，对其他团体了解的越多，对以后满足更宽广的需求时就会越有价值。他们开始认识到 XML 可以实现以数据为中心、以文档为中心、以形式为中心、以协议为中心和以过程为中心的所有信息视图的集成以及对这些视图的处理。XML 和与它相关的标准第一次实现了数据的互操作、内容的操纵、内容共享和重用、文档汇编、文档安全性和访问控制、文档过滤、文档格式化，覆盖了所有的规范和所有类型的设备和应用程序。随着工作重点逐渐转向下一类标准，并将 XML 日益增加的复杂性和多样性带来的益处和风险考虑进来，这种协作和讨论仍会继续。
如今 XML 世界的一些最重要的特性和十年前的还很相似。
散文式和结构化记录
有时也称为文档/数据的划分，这个问题试图将来自文档管理和电子消息传递的文档/数据同 DBMS 和分布式编程的文档/数据分离开来。一些人喜欢按照散文式的方式来设计 XML。想像一下一本书 —— 标记语言有时被嵌入到文本中(例如一个强调的单词)，顺序在这里十分重要。而另一些人则希望以类似数据库记录的方式来设计 XML —— 有很多重复，顺序并不很重要，标记语言总是和文本分离。显然，根据 XML 的实际使用情况的不同可以从二者中选择一种合适的设计方式，但是对于在中间情形下应该选用哪种方法以及 XML 处理技术是否应该倾向于其中一种还存在很多争议。所有这些争论导致了在实际方法中的巨大分歧，例如支持 RPC 的 SOAP、支持基于 XML 的通信的 WSDL、ebXML 和 REST。
静态强类型和动态松类型
来自数据库和编程领域的人们经常希望使用他们熟悉的技术数据类型工具，而 LAMP 领域和支持散文式内容的人们则希望将 XML 的内容严格作为文本看待，而将其认为是支持的数据类型只能是在不十分严格的情况下。LAMP(最初的 Linux?、Apache、MySQL 和 Python/Perl/PHP)是一个很流行的术语，现适用于使用动态语言(包括如 Ruby 等语言)和开放源码数据库(包括 PostgreSQL)的轻量 Web 开发的整套原理。我给这种划分起了一个奇怪的名字：“bohemians versus gentry” 。实际上，对所有这些事情：从 W3C XML Schema Language(WXS) 和 RELAX NG 之间的竞争到对 XPath 2.0 和 XQuery 的支持和反对，它都负有一定的责任。
必须理解和必须忽视
“必须理解”阵营的人们认为坚持严格的模式(不论是 DTD、WXS、RELAX NG、Schematron 还是其他形式)和拥有对数据格式的全面控制非常重要。而主张“必须忽视”的人们则认为可以围绕一个可随意扩展的轻量模式建立格式，如果一个应用程序运行并跨越了一个它不熟悉的扩展，那么该应用程序应该采取一个不严密的方法并忽视这部分文件继续运行。前者认为可扩展性源于模式严谨的发展，而后者则更笃信非正式的协议和适度的特性降低。这场争论在很多领域都有所体现，例如 Web 上的微格式和 Web 服务的处理约定。
正式语义和非正式语义
W3C 的一些领导仅仅将 XML 看作是实现带有详细注释语义的 Web 的一个垫脚石，这样自治代理可以在最少的人为参与下有效地导航互相链接的信息。其他人则认为目前这还不是一个可行的目标，并且 XML 不应该担负实现此功能所需的过分结构化的元数据。那些希望 XML 有很正式的语义的人们试图将 XML 结构与注册库或知识表示格式联系起来。我在本专栏中特别针对这个主题进行了详细的论述。
简化性和稳定性
在 XML 早期，一些人认为 DTD 特性、实体等会不必要地使标准复杂化，有些人甚至声称属性是不必要的复杂性因素。其他人则认为如果削减了 XML 的这部分特性将削弱它的兼容性，导致 XML 退化为表达信息的固定基础。一部分人喜欢用类似 clean-room XML 2.0 的东西去掉他们认为是缺点的部分。另外一些人则青睐谨慎细致的改进，更侧重于在核心标准之上构建系列技术。
其他比较大的争论则针对一些范围较窄的技术方面的问题：XML 名称空间、二进制 XML、XLink 等，但是不管您对 XML 的哪个特定领域感兴趣，以上介绍的内容都广泛存在。从众多不同的角度了解问题非常有益，这样您就可以利用所有的工具来进行最为有效的决策。
关于 “Thinking XML” 的思考
本专栏开始的时候，其重点就放在如何综合各种行业和技术以在 XML 之上构建垂直标准。IBM Systems Journal 的一篇文章 “Emerging patterns in the use of XML for information modeling in vertical industries” 对这个问题进行了周密的探讨，借用了来自 Open Application Group，Inc. (OAGi)、Association for Cooperative Operations Research and Development (ACORD) 和 OpenTravel Alliance (OTA) 的例子。它提出了一些有用方法来对这些创新项目进行分类，它还给出了一些技术设计模式，这些模式关注于怎样使用 XML 和 Web 服务的细节。这篇文章间接提到了我在前面所讨论过的 XML 实际应用的众多方面的内容。同样它也涉及了我在Thinking XML前几期文章中曾谈到过的一个区别：XML 词汇表的自顶向下和自底向上模型。在讨论自顶而下模型时，这篇文章还提供了一个比我之前在其他文献中见过的都要好的描述：
与 ad hoc 开发不同，正式的模型样式被一些组织用来开发标准消息。这种正式的自顶向下模型样式开始出现在垂直型 行业组织。在这种样式中，建立在一些信息模型形式基础上的消息规范越来越严格。伴随着技术、方法学和工具的发展，会产生相关培训课程以保证一致性。在这样的环境下，很大一部分精力花费在定义需求、用例和角色，以及信息模型上。还会经常用到一个 Unified Modeling Language (UML) 配置文件。
这种样式为在非正式环境下难以标准化的元素提供了标准化的机会。一个严格的方法学有助于信息使用的规范，而这会在信息元素、其基数甚至其语法的包含性方面产生影响。这种严格性随之而来的结果是出现了库和注册表关注点，它们在信息组装和上下文用法定义方面起了关键作用。
接下来又以 HL7 为例举例说明这种模型方法：
先进的 Health Level 7 (HL7) 组织是几个采用了自顶向下建模模式的组织之一，HL7 是一种医疗信息标准，在该标准中越来越多地将 XML 看作一种编码技术而非信息源模型。这种模式有望增加推广业务的互操作性所需的标准的精度、减少歧义、降低复杂性和成本。
这非常有趣，因为它解释了自顶向下建模怎样试图排斥 XML，使它对比其他信息架构而言不过是多了一层薄的外壳。这也恰恰动摇了此篇文章前面对 XML 基础的讨论。自顶向下建模对已知应用程序的互操作有所优化，同时它也折衷满足了 XML 独立于应用程序域的需求。在短期内这可能会降低复杂性和成本，但是总会有步 20 世纪 90 年代 COBOL 危机的后尘的危险。就抽象随时间而不断增加的代价而言，有时候独立于特定的处理模型还是值得的，认识到这一点很重要。XML 应用程序的自顶向下建模所存在的问题是 XML 经常会被这个应用程序锁定，将有价值的信息移往将来的应用程序也可能会非常棘手。
从进程中分离信息
在某些方面，这篇垂直型行业文章的确显示了对进程集成的一些偏见，尤其是在它所强调的面向服务的体系结构(特别是 SOAP 和 WSDL)如何能够推动 XML 的设计这一方面。我认为该主旨文章在对 XML 应用做如下描述时就暗示了这一观点：
在信息隐藏、广义性、封装性、编程语言和方法学的重用方面的价值 —— 这项工作开始于 20 世纪 60 年代初，那时 Algol 和 Pascal 语言刚刚出现，随后则出现了 Simula、Smalltalk、C++、Modula、Java 和 C# 等面向对象的语言。XML 是一个杰出的用来定义接口以封装抽象的通用方法。
很多 XML 专家(包括我本人)认为将 XML 和应用程序域捆绑得太紧是个非常危险的做法，这会丢失它的一些关键优点。XML 或许可以被看作典型接口技术的逆转。它强调打开数据而不是隐藏数据。XML 不会在隐藏数据的同时提供一个接口方法的扩展来定义过程，XML 更适合于数据驱动交换，其中交换的内容是该契约的基础，每一方都可以用自己的方式自由应用应用程序语义。参与者需要遵守业务处理限制，但是这些应该被分别表示，而不是捆绑在 XML 之内。当然，这种限制同样可以用 XML 格式来表示，但是这又和交换的数据的实质有所不同。其想法就是当行业机制、规范和应用程序技术不可避免地发生变化时，数据仍然保持有意义。业务过程和应用程序过程或许也会分离，与 XML 词汇表比较而言，后者可能更适合用非 XML 接口定义语言(IDL)表示。然而最重要的一点是基本的信息可以继续存在，而这又可以通过将基本信息与其他事物完全分离来最佳实现。
在我看来 XML 的全部未来都寄托在这个问题之上。XML 是否将仅仅能为时兴的紧耦合交换技术提供一种注释性的便利?还是会继续影响人们看待交换的基本方式?除非各种行业都能认识到 XML 是一个能够从机器分离信息的重要工具，否则 XML 很可能会随着时间的流逝而被废弃，因为如果没有这种分离信息的优势，它的成本会显得相当大。XML 要比传统的 CORBA、EDI 和 ASN.1 交换格式更加臃肿，如果 XML 仅仅是这些格式的一个可读版本，那么很难解释 XML 缘何能够取代它们。
结束语
IBM developerWorks 最近更新了它的 “New to XML” 网页。每天都有人访问 XML 社区。XML 如此流行以致于程序员、数据库分析师、技术作家、系统集成者等都争相希望在他们正常的业务过程中进行 XML 的处理。如果 XML 能跟上技术的变迁，那么教育后来者要记住 XML 的基本目标和动机是很重要的。XML 是关于持久性数据的，但是单独使用 XML 本身并不一定会使数据持久。这次 XML 的十周年纪念日(也许有小的误差)是一个很好的机会来探讨当我们很信任地把如此众多的数据交给 XML 技术时，怎样确保我们可以获得长期的利益。我个人非常期盼在未来几年之中能够看到进一步的对 XML 过去、现在和将来的技术及非技术方面的评价。当然，我将继续在本专栏讨论如何巧妙地使用 XML 获得标准化格式的更多益处。
