作者: Elliotte Rusty Harold, 　出处:developerWorks 中国,　责任编辑: 叶江,　
2007-03-08 08:10

　　对于XML来说，2006年是静悄悄的一年。2007年是否会更令人激动呢？答案是肯定的，Elliotte Rusty Harold 预测会这样……
　　对于 XML 来说，2006 年是静悄悄的一年。2007 年是否会更令人激动呢?是的，Elliotte Rusty Harold 预测会这样。

　　自五年前社区将 XML 的快速发展应用到 Web 服务以后，2007 注定会成为最激动人心的一年。XQuery、Atom、Atom Publishing Protocol (APP)、XProc 和 GRRDL 都有望带来新的动力。一些老一点的技术如 XForms 和 XSLT 也焕发出新的生命。XML 技术在 2007 年能够更好地发挥其作用。

　　XQuery

　　至少近四五年以来 XQuery 一直被称为 “下一年” 技术，但是在 2007 年它终于来临了。首先，XQuery 1.0、XPath 2.0 和 XSLT 2.0 这些已完成的规范终将成为真正的推荐标准。事实上，当我在最后一次编辑本文时这已变为现实。:-)

　　此外，XQuery 的更新部分正在大踏步地前进。也许今年不会完成，但对于实现来说已经足够稳定，只要用户不介意每次发布新的草案时都要稍微修改一下代码。这种情况在年内只会有所改善。

　　另外，javax.xml.xquery beta 版也将在 2007 年发布。这是把 Java™ 程序和 XQuery 引擎、数据库连接在一起的标准 API。可以将其看作是 XQuery 的 Java Database Connectivity (JDBC)。它允许在 Java 代码中混合使用 XQuery。随着 2008 年 Java 7 的发布，它将成为 Java 类库的标准组成部分。

　　最后，原生 XML 数据库正在猛烈冲击市场并引起了用户的注意。在低端市场，eXist 和 Sleepycat(现在属于 Oracle)的 dbXML 越来越好。混合解决方案如 Oracle Database 10g Release 2 和 IBM® DB2 9 PureXML 将在需要混合使用传统表和一些文档的原有用户中推动 XQuery 的采用。纯 XML 数据库如 Mark Logic 将继续转变为能够承担入门费用的大型发行商。

　　最重要的是，和关系数据库以及结构化查询语言(SQL)相比，使用原生 XML 数据库和 XQuery 将更容易解决众多问题。SQL 数据库强大而有用，它们不会消失，但是从来都不能很好地适合 Web，而今天基于 Web 的应用程序越来越多。WordPress 和 MediaWiki 这类程序居于关系数据库的顶端，仅仅因为这是开发人员方便使用的工具而不是适合需要的恰当工具。到年底的时候，至少会看到 Wiki、内容管理系统、blog 引擎其中的一种将建立在 eXist 或其他 XQuery 数据库的基础上。保守估计，这三种产品至少一种或者全部产品将把 XQuery 注入从理论问题变成实际问题。

　　办公文档是推动 XML 数据库采用的另一股推动力量。大量的企业和非企业数据根本不是用 XML 存储的。通常保存在个人计算机上的 Microsoft® Word、Excel®、PowerPoint® 文件。现在这些程序都保存为原生 XML，因此有可能在集中管理的 XML 数据库中存储这些文档。

　　Atom 发布协议

　　如果让我选择下一年的热门话题，那么我会选择 Atom 发布协议(APP)。APP 起初是作为发布 blog 内容的标准方式提出的，但后来证明它能做更多的工作。APP 和 Atom 对于 Web 创作来说，就像是超文本传输协议(HTTP)和超文本标记语言(HTML)对于 Web 浏览。Tim Berners-Lee 一直把 Web 解释为一种读写媒介，但事实并非如此。过去 15 年中只实现了系统的发布/读取部分。只能使用局限性很大的 HTML 表单或者非 HTTP 方法如文件传输协议(FTP)实现写的功能。

　　APP 定义了所有服务器都能实现的发布新内容的标准方式。独立的软件厂商可以编写自己的能够和不同服务器上的 APP 服务对话的编辑工具。最终我们将能使用类似 Word 和 Emacs 这样的功能完善的编辑器编写 Web 内容，而不是浏览器中那种简单的工具。上传内容可能变得和今天在本地硬盘上存储文件一样简单。

　　APP 是第一个基于 Web 体系结构 Representational State Transfer (REST) 的重要协议。目前多数系统仅使用了 HTTP 的一个子集，通常只有 GET 和 POST 而没有涉及到 PUT 或 DELETE。很多系统如 SOAP 和 Web-based Distributed Authoring and Versioning (WebDAV) 是与 HTTP 设计相矛盾的。相反，APP 可以与 HTTP 工作而不是对抗它。

　　如果我的预测正确并且 APP 成功的话，将带来两方面的重要影响。首先，APP 将成为告诉人们如何设计 REST 化的新系统的好例子。其次，它将迫使大量原生防火墙和代理服务器重新配置，以便除 POST 和 GET 之外还允许 PUT 和 DELETE 通过。这样有助于避免任何内容都要通过 POST 传输，使其他 REST 化的应用程序看起来更加真实。

　　除了破坏代理以外，妨碍全面采用 REST 的另一个问题是浏览器表单只允许使用 GET 和 POST 方法。这种情况也将改变，APP 是推动这种改变的主要原因。XForms 和 Web Forms 2.0 也准备进行 REST 升级，在现有的 GET 和 POST 之外增加 PUT 和 DELETE 作为浏览器操作。只要浏览器厂商实现并且 Web 开发者社区掌握了这些技术，这些方法将改进 Web 安全性。但是这需要时间，全面的影响直到 2008 年年初才能看到。

　　表单

　　我看不到 WHAT 工作组的 Web Forms 2.0 有多少前途。它是一些华而不实的工具，但是没有改变任何东西。只是一种普通的、表面的改进，而非革命性的变化。一些 Web 开发人员可能会采用它，但是多数不会，就像 Microsoft 那样。通过 JavaScript 可以为 Windows® Internet Explorer® 提供很多功能，这些功能和目前用 JavaScript 实现的功能相同。只不过更加标准化罢了。Web Forms 2.0 没有为表格带来任何新东西，它并不能在根本上改变人们思考和设计表单的方式。

　　相反，XForms 正准备起航。该规范数年前就已经完成，其实现也终于迎头赶上。尽管浏览器支持有限，但是在内部网中采用越来越广。为何 XForms 取得了成功而 Web Forms 2 却失败了呢?因为 XForms 更加先进。和 Web Forms 不同的是，它改变了房子的架构而不仅仅是涂料的颜色。开发支持 XForms 应用程序不同于开发传统的基于 HTML 表单的应用程序。最根本的在于 HTML 表单总是敷衍了事：讲求快速而不讲究地解决简单问题。它们从来没有打算承担开发人员加到其上的负荷，多年来已经摇摇欲坠。它并不能作为替代桌面应用程序以及引入 Web 2.0 的坚实基础。众多 Web 2.0 应用程序使用 JavaScript 而非 HTML 有一个重要原因：使用 HTML 表单不能满足需要。

　　XForms 又回到了绘图板，重新定义了体系结构。形成了互相独立的模型、视图和控制器。使用 XForms，Web 应用程序开始看起来像是专业人员设计的干净程序，而不是在大学低年级学过一学期 Basic 的平面设计师平凑而成的东西。

　　当然，最主要的优点来自编写更复杂应用程序的人们。并非每个人都需要 XForms 的全部功能。简单的联系人表单、邮件列表订阅、在线投票、一键购物等使用传统 HTML 表单就足够了。但是，多页校验、blog 管理、防火墙管理这类更复杂的表单将从 XForms 获益匪浅。如今越多的使用客户端 JavaScript 和服务器端 PHP 管理表单，将来从 XForms 获得的好处越多。声明式标记将取代很多脆弱的过程性代码。