| XML 的未来 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 摘自: IBM developerWorks China 被阅读次数: 43 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
由 yangyi 于 2008-05-08 19:22:44 提供 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
级别： 中级 Elliotte Rusty Harold (elharo@metalab.unc.edu), 副教授, Polytechnic University 2008 年 2 月 28 日 完成了“XML 2007 年度回顾”，又到了预测 XML 的未来的时候了。在本文中，Elliotte Rusty Harold 对 XML 领域在 2008 年以及未来的发展方向作出了新的预测。 发展的车轮转动缓慢，但依然在转动。水晶球或许有些朦胧，但 XML 未来的轮廓已经逐渐清晰。准确的时间线依然不那么明确，但 XML 的走向却并非如此。XML 的未来在于 Web，更具体地说，就是 Web 发布。 说起来似乎很有趣，毕竟 Web 的意义就在于发布。Web 最初的设计初衷就是作为一种发布信息的机制。它还能做什么？太多了。在过去的三年中，我们已经看到人们对 Web 应用程序的兴趣呈爆炸式增长，远远超越了传统 Web 站点。文字处理程序、电子表格、游戏、绘图工具等等全部迁移到浏览器中。在未来几年中，这种趋势会进一步加速，因为 Web 浏览器中的本地存储使其脱机工作的可能性越来越高。但 XML 依然牢固地植根于 Web 1.0 的发布，而且这一点依然非常重要。 有些美梦将在今年成为现实。Sun 的网络部署应用程序之梦正在实现，尽管这些应用程序选择的语言是 JavaScript™，而不是 Java™。这或许已经尽失先机：Sun 本应在十年前交付这一切，但令人遗憾的是，Sun 从未有过实现这一切的经验、愿景，甚至兴趣；现在 Sun 正奋力发出最后一击。 Netscape 的以浏览器取代操作系统的梦想也将在今年变成现实。Netscape 曾经预想看到这一切。遗憾的是，它不具备实现这一切的商业头脑或品味。尽管如此，Firefox 和 Mozilla Foundation 作为 Netscape 的直接继承者，依然在开创新天地的过程中扮演着关键角色。 对于 Microsoft® 来说，更年轻、更机敏的竞争对手取代其地位的噩梦也将变为现实。这家公司被 Sun 和 Netscape 吸引了大部分注意力，未能及时注意到 Google 正悄然侵蚀着 Office 和 Windows 的地位，多种来源的 GMail、Google Docs 和类似的应用程序迅速实现了底层操作系统无关性。 无疑，您依然需要使用操作系统来运行浏览器，但人们逐渐不再关注使用何种操作系统，就像过去十年中人们不再关注其 PC 的厂商是哪家一样，只要它运行的是 Microsoft Windows® 就行了。现在，没有人会关注是谁制作了他们的操作系统 —— 只要它运行的是 Google。操作系统正在被改进，就像 PC 一样。Windows 的主宰地位遭遇到了空前的挑战，使 Microsoft 犹如坐守空城。
作为一种被广泛宣传的技术，XML 对于这种情况并无对策。尽管反对者在 Asynchronous Java Script + XML（Ajax）的大旗下活动，尽管 Ajax 中的 x 代表 XML，已没有人将 XML 用于这些用途。几乎从这个缩写词出现起，Web 开发人员就开始编写 JavaScript 代码，将其作为数据传递，然后使用 问题在于一种 API，而非数据格式。更具体来说，这是一种 API 导致的问题：Document Object Model (DOM)。大多数开发人员了解 DOM 之后便不再了解其他任何替代性 API。他们无法辨别 DOM 和 XML，因此也会将其对 DOM 根深蒂固的厌恶与对 XML 不甚明朗的反感混淆在一起。DOM 并非获得最广泛认可的出色 API，而是最糟糕的常用 API。几乎不可能设计出另一种更糟糕的 API 来处理 XML。但开发人员非常抗拒学习新知识。在 Java 社区之外，JDOM 和 dom4j 已经取得了一些进展，像 E4X 和 Amara XML Toolkit 等更出色的替代产品依然不为人所知，也受到了很大的阻力。JavaScript Serialized Object Notation (JSON) 的特征也是它最大的弱点。JSON 是可执行的 JavaScript 代码，不需要 JavaScript 程序员学习任何新内容即可投入使用。因此更安全的数据传输格式未得到广泛的接受。
DOM 是 XML 肩上的沉重负担。它是软件开发中更广泛地采用 XML 的最大阻碍。XML 在编程中已经发挥了自己最大的作用，但在身后留下沉重的包袱。除非万维网联盟（W3C）和浏览器厂商抵制 DOM，并以一种健全的替代方案取而代之（最好是几种健全的替代方案：尝试使用一种 API 完成一切操作正是 DOM 的一大败笔），XML 在软件开发领域中一直任其发展 — 特别是 Web 软件开发（逐渐地，这也成为惟一一种重要的软件开发）。W3C 应满足在职开发人员的需求，在必要时取缔一种失败的规范。 XML 是否已经失去存在的必要？不，我相信 XML 有着光明的未来。那不是运用传统或 Web 软件开发能够实现的未来。要理解 XML 在 2008 年或更远的未来将走向何方，首先必须回顾 1997 年或者更早的时候，了解 XML 的起源。
您必须了解，XML 的意图从来就不是在软件开发中使用 — 至少在早期不是如此。早期规范 — XML 1.0、XPath、Extensible Stylesheet Language Transformation (XSLT)、Namespaces in XML、Extensible Hypertext Markup Language (XHTML) 和 DOM — 中并无任何内容集中关注软件开发人员的需求。如果 XML 最初的设计目的就是软件开发，那么就应该像 JSON 那样支持列表、映射和数据类型。XML 最初的设计目的是发布，更具体来说是发布 Web 页面。 XML 派生自有着 20 年历史的 SGML 技术。几乎就在 IBM® 的 Codd 了解到如何通过将数据拆分为较小的无序片段来设计数据结构的同时，同处 IBM 的 Charles F. Goldfarb、Edward Mosher 和 Raymond Lorie 也领会了如何设计不适合作为表的大型有序文档的结构。Codd 考虑的是业务数据库和财务记录。Goldfarb、Mosher 和 Lorie 考虑的是业务文档，如年度报告和飞机技术手册。 SGML 最初的目的是解决发布问题：如何编写、维护、更新、打印、搜索和读取可能跨多种平台使用的、包含多达上万个页面的文档，而那些平台可能具有不同的处理器、字符集、自然语言、操作系统和供应商。SGML 在具有这些需求的政府机构和军事部门中取得了一定的成功，O'Reilly 等出版商有时会使用这种技术，但总体而言，SGML 对于大多数需求来说太过庞大和复杂 — 即便是对于出版业也是如此。 SGML 最大的成功之处也是它最大的失败：HTML。HTML 旨在成为一种 SGML 应用程序，但几乎没有任何编写浏览器、编辑器或 Web 页面的人对 SGML 有着深入的理解 —— 除了这个缩写词代表的意思（许多人甚至这一点都不了解）。扩展的引入杂乱无章，很快使任何声称 HTML 必须与 SGML 一致的呼声销声匿迹。1996 年前后，即便尚存的少数昂贵的 SGML 工具也无法抗拒实际的 HTML 对于 Web 的侵蚀。 这正是 XML 最初试图挽回的情况。一方面，它希望将 SGML 简化为一个合理、标准的子集，使所有人都能认可，并忠实地加以实现。其愿望是：这种更简单的规范能够获得 SGML 未曾达到的更广泛的采纳。在这个方面，XML 取得了很大的成功。 另一方面，XML 旨在为构造良好的 Web 奠定基础，通过减少恼人的跨浏览器不兼容性和特异性实现。在这方面，XML 可以说是失败的。XML 和 XHTML 只是引入了另外一种浏览器必须处理的 HTML 方言，而没有向取代 “标记大杂烩（tag soup）” 的目标接近分毫。 无论成功还是失败，XML 的目的都是发布：图书、手册以及（最重要的）Web 页面。XML 并未针对发布以外的软件开发进行优化或规划。最初并未预期或计划将其用于配置文件、远程过程调用、对象串行化、数据库转储和类似的面向开发的任务。因此，毫无意外，XML 并非总是非常适合这些需求。无论如何，XML 确实为开发人员提供了某些前所未有的东西：一种独立于平台、语言无关、国际认可的数据格式，以及可以轻松获取的大量高质量、免费的解析器。这种组合不可避免地使许多程序员忽视了数据类型（如整型和浮点）和基本数据结构（如列表和映射）的缺陷。 但由于这并非 XML 的意图，因此也不能据以评价 XML，或许，您应该着眼于它最擅长的方面和未来愿景。为此，必须了解 XML 最初的设计意图：发布，特别是 Web 发布。Web 发布有三个部分：
读者部分已经完成，那就是浏览器。所有主流浏览器现在都支持 XML。但编写和发布部分以及两者之间的联系才刚刚起步。
在发布一个文档之前，必须先完成创作，在这里并无争执。XML 大获全胜。目前，所有主流办公套件默认情况下都将其文档保存为压缩的 XML 格式。这其中包括 Microsoft Office、OpenOffice、StarOffice、WordPerfect Office 和 Lotus® Notes®。即便图形图像应用程序（如 Adobe® Illustrator®）现在也能将文档保存为 XML 格式。最值得一提的坚持不使用 XML 的产品就是 Apple 的 iWork，但它将在新的一年中加入这一联盟。
这种形势的变化尚未得到充分认可，主要是由于 XML 对于用户是隐藏的（也应该是这样）。典型的电子表格用户没有理由了解或关注 Excel® 如何在磁盘上安排其持久数据。但是，文本 XML 结构使得第三方可以更轻松地对格式进行反向工程，并与应用程序交互。尽管 XML 的词汇像 OpenOffice XML 一样未得到很好的归档并且比较紊乱，但依然比使用过去那种晦涩难解的二进制格式要轻松上千倍。如果这种格式更加敏感、受平台的约束和遗留内容的制约更少 — 比如说，OpenDoc 格式 — 那么使用起来会更加轻松。 2008 年，我们依然会看到许多关于在 Office 文档中使用哪种 XML 词汇表的争论，而且双方势均力敌。我猜测 Microsoft 无法实现在二月份将 OOXML 声明为 ISO 标准的目标，但我并不确定。无论如何，有一件事是确定无疑的。Microsoft Office 将继续将市场份额输给 OpenOffice、iWork 和其他竞争对手。 这并非由于 Office 是一种糟糕的产品（并非如此）或封闭的源代码（确实如此），而只是因为不进则退的道理。它没有成长的空间。惟一的问题就是它将在多久之后陨落。对于 Microsoft 的统治地位，目前最迫切的隐患就是越来越多的政府机构将跟随荷兰和挪威的脚步，强制使用 OpenDoc 和/或开源解决方案。对于 Microsoft 来说，麻烦较少但依然值得关注的另一个问题就是低价 PC 的盛行，这使 Windows 和 Office 占用了系统总成本的 50% 或更多。从某种程度上来说，Microsoft 已经开始意识到这种形势，推出了低成本的 Office 教学版，任何开展教学工作的用户、有学生的家庭、在上世纪某时刻参加过语言学校的人，或者被认为可能是教师的人都可以轻松获得这一版本。但在 “不让左手知道右手做的事情” 这种一贯的传统下，Microsoft 也在 Office 中加入了版权保护。尽管这种做法很可能会降低盗版率，但也促使更多的用户寻求开源替代产品。 既然所有 Office 文档都采用了 XML 格式，那么将一种格式转换成另一种格式也将无比轻松。2008 是 XSLT 诞生的第 10 个周年，它是 XML 家族中惟一一种可能改变游戏规则的技术。其崭新的 2.0 版本更加强大。很快，竞争格式之间的转换将变得非常简单明了，使大多数人不再关注自己使用的格式。某些样式和宏将在这次转型中淘汰，但这些特性在大多数文档中都不会用到。由文档格式引起的供应商锁定将不再是问题。 当然，最重要的转变并非从 OpenDoc 到 OOXML 或反之，而是从 OpenDoc 或 OOXML 到 XHTML。OpenOffice 和 Microsoft Office 中的 HTML 导出器同样糟糕。我们只能期待第三方开发人员取而代之。最重要的是，期待独立企业开发人员和 Web 主管开始为其站点发布自定义模板。这将使普通人能够在 Microsoft Word 中进行创作 —— 就像他们习惯的那样，然后直接将作品上载到本地内容管理系统。编辑和审查工具可构建于其中。由于机器生成所有标记（人们看到的是熟悉的 GUI 界面），自然而然也就获得了良好的格式。在 2008 年底之前，大多数 Web 站点依然不会是格式良好的，但格式良好站点的百分比将超过当今的数量。 XSLT 和 XML office 格式还将公开大量隐藏数据。无数业务文档隐藏在文件系统的角落中，已有十年或更久的时间未被阅读。其中大多数在今天看来已经毫无用处，但其中有一些文档还包含被遗忘的重要信息，因为没有人能搜索到它们。企业开发人员将从现有 Office 文档中提取并重新定位信息，第一步就是自动转换为较新的基于 XML 的格式，然后使用 XSLT 和 XQuery 使数据可被用户找到。 如果创作工具是传统 Office 程序，如 Word 或 OpenOffice Writer，服务器上将怎样进行处理？您又要如何将内容从客户端传递到服务器？在这里，2007 年发布的两个重要的 1.0 版本发挥了很大的作用：Atom Publishing Protocol (APP) 和 XQuery。
按照传统方式，在培训非技术人员编写 Web 内容时会遇到两个难题：教他们了解语义标记，向其展示如何使用 FTP。（切记，许多非技术用户甚至不会使用标准的 “打开文件” 对话框。他们将一切内容都存储在 “我的文档” 文件夹或者桌面上。如果意外地将文件保存到了其他位置，他们将无法找到该文件。程序员了解层次结构，但许多用户并不会用抽象的方式进行思考。） 支持 XML 的文字处理程序（如 OpenOffice 和 Microsoft Word）解决了第一个问题。Atom Publishing Protocol 解决了第二个问题。APP 为 Web 创作所做的贡献与 HTTP 为 Web 浏览所做的贡献相同：提供一种标准协议，使各种独立的客户端和服务器能使用它来通信，而无需先行达成协议或共享概念模型。 独立软件供应商可以编写起自己的创作工具来与不同服务器上的 APP 服务器会话。这些工具可以是自定义的编辑器或 Word、OpenOffice 等产品的插件。上载内容可能像如今在本地硬盘驱动器上保存一个文件那样简单，在某些情况下甚至更简单。创建新文档之需要一个作为发布目标的 URL 以及用户名和密码。（像 Wiki 这样的站点甚至不需要用户名和密码。）要编辑文档，只需要该文档的 URL 即可。
现在，您了解了在 2008 年将如何编写 XML（Word 或 OpenOffice），也了解了如何将其发送到服务器（APP）。那么最后一个问题就是：将这些出色的 XML 放在哪里。 传统上，这个问题有两种答案。第一种是将 XML 保存在文件系统中。第二种是将其填入关系数据库的二进制大对象（BLOB）中。两者都不够完善，对于 Web 站点来说都不够完美。 文件系统是简单、可靠、容易理解的技术，但缺乏高明的搜索功能。它们倾向于在十几个不同的位置重复相同的数据，它们不了解所保存文档的内部结构，也不能提供子文档粒度。 关系数据库是无特定顺序、重复率低的较小数据片段的理想存储。但 XML 不符合任何一种特性。尽管任何关系表都能轻松转换为 XML 文档（只是将每一行作为一个元素，每个字段作为一个属性或子元素），但反向转换并非如此。许多 XML 文档都包含明显的顺序、相关的空格、混合的内容、重复但有差别的内容、无法预知的嵌套元素和其他特性，不适合使用关系表作为数据存储。具体来说，Web 页面（包括 HTML 和 XHTML 页面）就具有所有这些特征。确实，您可以 在关系数据库（MySQL 似乎更适合其他场景）中存储 HTML 和 XML 文档，但其结果既不美观，运行速度又缓慢。如果将文档分割成许多较小的片段，可以搜索、选择和对数据重新排序。但最终要花费大量金钱才能实现可以接受的性能。维护和开发也将成为梦魇，因为 SQL 查询将占用半页以上内容，使用复杂的逻辑来完成简单的任务，而这些任务并非 SQL 所长。 替代方法就是在 BLOB 中存储各文档。此方法既快速又简单。但无法再去选择数据的某些部分，也无法合并不同的文档。应用程序逻辑延伸到 PHP、Ruby 或其他某些服务器端的框架。对数据库的使用与替代性文件系统相差无几，只是隔离特征略占优势。 我们需要的是一种专为处理典型 Web 文档的层次化结构而设计的数据库，而不是将其拆分开来。现在，这样的数据库终于出现了，它们不但适用于不同领域，而且稳定、随时可供使用。在低端，eXist 和 Berkeley DBXML 正在逐渐完善。在高端，昂贵的大型机 XML 数据库（如 Mark Logic）将继续转变着能够负担得起引入成本的大型出版商的观念。混合式解决方案（如 IBM DB2® 9 pureXML™）将促使需要将文档与表格数据混合的客户采纳 XQuery。 与此类早期产品比较，新产品更加稳定、更可伸缩，而且更可靠。最重要的是，它们现在共享一种标准语言 XQuery 1.0，这种语言是在历经多年开发之后发布的。将应用程序从一个数据库迁移到另一个数据库的可能性通常被夸大了，但将开发人员的技能从一种服务器迁移到另一种服务器的必要性得到了很好的认识。没有人希望学习一种查询语言的六种不同方言，然后每六个月重新学习一次。现在，他们不会再有这样的烦恼。 XQuery 的更新部分进展非常迅速。在 2008 年很可能不会完结，但它已经足够稳定并可以实现了，只要用户不介意在每个新草案发布时对其代码略加修改。在这一年，情况将逐渐好转。 最终，在 2008 年，我们应该看到
查询最终为生产做好了准备，APP 则为突破做好了准备。如果我正考虑为 XML 投入资金或时间，那么这些都将是我关注的技术。世界并不需要另一种内容管理系统、blog 引擎或者公告板；但如果这些技术使用本地 XML 数据库存储和搜索内容，并通过 APP 发布内容，它们必将成为实用的热门技术。 我还期望看到多种开发人员工具。我知道，我提到过 XML 在软件开发中已无生命力可言，但或许还有一息尚存。JSON 给我们的教训就是：许多应用程序并不需要或想要 XML 支持的灵活的结构化数据。假设一种用于编码列表和映射的基本 XML 格式包含类型数据。可能像清单 1 所示代码那样简单。 清单 1. XML 的一种基本数据格式
然后，假设您使用 Java、JavaScript、Python、Perl、Ruby，以及其他可将文档解析为其语言的本地数据结构的语言中编写了一些简单的库。是否有可能重现 JSON 的案例，但这一次不再存在安全性问题，而且提供 XML 支持的一些增强的灵活性？是否存在隐患？ 学习
获得产品和技术
讨论
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
