对 XML 来说，2007 年又是发展较为平缓的一年。但是在这一年中，一些重要的规范都升级到了 1.0 版，XML 在信息发布(Web 和传统形式)方面得到持续发展。更重要的是，REST 与 Web 服务的碰撞引起了轩然大波，整个 Web 服务领域产生了重大变化。引起这一巨变的最主要技术是 POX(plain old XML)，POX 文档可以通过标准 HTTP 传送，而且不会被任何模式或规范羁绊(一些人在多年前就预感到这一结果，但是正如 Roy Fielding 所说，行业最终会亲自检验)。
REST 并不是惟一隐含其强大功能的技术。XML 的全部潜力也即将充分发挥。在这一年里，Atom 发布协议(Atom Publishing Protocol，APP)和 XQuery 升级到了 1.0 版，而它们带来的影响才刚刚开始。
在过去十年中，XML 经历了无数次挑战，不管是来自功能强劲的技术，还是来自名不符实的技术(YAML、SML、S-表达式，以及其他遭竞争淘汰的技术)，但是 2007 年 JSON 的流行却是对它最大的挑战。尽管 JSON 的适用性有限、存在安全问题，而且应用程序编程接口(API)设计并不完善，但是这并没能阻碍它的进一步推广，明年其使用率似乎还会继续增长。
1 月
在过去 5 年中，XQuery 总是被认为是 “下一年” 就会实现的技术，这个承诺终于在 1 月份得以兑现，XQuery 1.0 在 1 月正式发布。一些纯 XML 数据库已经实现了它，包括 Mark Logic、eXist、Sedna 和 Berkeley DB XML。一些混合数据库也提供了对 XQuery 的支持，包括 IBM® DB2® 9 和 Oracle 10g。XQuery 还被一些独立产品采用，包括 Michael Kay 的 Saxon 和 DataDirect XQuery。
但是故事并没有就此完结。XQuery 只是整个解决方案的一小部分。用 CRUD 的话来说，XQuery 是不包含创建(Create)、更新(Update)或删除(Delete)的读(Read)操作。不得不通过专用的扩展来添加这些必需的功能。这意味着不能轻易地将一个应用程序或数据库从一个实现移动到另一个实现。更严重的是，开发人员不能使用标准语法，很难雇佣到经验丰富的 Mark Logic 程序员来处理 DB2 9 应用程序(程序很少在平台之间转换，但是开发人员经常这么做)。XQuery 需要一个更新(和创建、删除)工具。World Wide Web Consortium (W3C) 在 8 月发布了 XQuery Update Facility 1.0 的 last-call 草案，而且供应商已经开始付诸实现。如果幸运的话，那么 XML 社区有望在 2008 年看到该草案通过 last call 阶段并形成最终版本。
在这一年中，XQuery 工作组也发布了第一批 XQuery 1.1 需求。一些最重要的新功能可能包括异常处理、扩展函数、函数指针和/或 lambda 表达式。幸运的话，只需五六年时间就能实现这些功能。然而，最好在 XQuery 真正流行起来之前就开始实施，而且任何规范的的更改都需要几十年的努力，就像 SQL、Fortran 和 C 的情形一样。
尽管 XQuery 是一种完整的编程语言 — 它可以完全取代 PHP、静态 HTML，以及任何其他 Web 框架 — 在不久的将来，您将需要将其与用传统语言编写的程序进行集成。因此在这一年提议将 XQuery API for Java (XQJ) 加入 Java Community Process 最终草案是一个很不错的主意。可将这看作 JDBC for XQuery。Saxon 9 和 Data Direct XQuery 3.0 已经提供了对 XQJ 的支持，而且一旦明年完整的规范发布，更多的供应商将会参与到其中。
2 月
在最短也是最冷的 2 月，每个人都呆在家里，也没发生太多事情。Saxon、TagSoup 和 WebCGM 都发行了新版本(您也许会问，什么是 WebCG？)
在这个月，发布了 XForms 1.1 的 last-call 工作草案，其中添加了一些重要功能，包括对 PUT 和 DELETE 提交的支持。但是要使 XForms 成为最后的推荐标准，这一年剩下的 10 个月也许还看不到这一结果。11 月最多实现 XForms 1.1 推荐标准。因此也许等到明年才能实现。
在这一年中，大多数主流 XForms 供应商都从不同角度发布了其产品的更新版本，包括 FormsPlayer、Chiba、Orbeon，以及 Mozilla XForms 扩展。不幸的是，何时将 XForms 支持内置到主流浏览器中仍然难下定论。
3 月
W3C 已经成立十余年了，它是 Internet Engineering Task Force (IETF) HTML 2.0 计划失败的直接产物。基于这样的历史，2006 年 W3C 果断放弃 HTML 确实有些令人震惊。直到现在，W3C 仍然如此地专注于 XML 和 Semantic Web，以至于都忘记了自己曾经支持过的一项技术。因此，在 2004 年，一些 Web 设计人员和浏览器供应商联合起来成立了 Web Hypertext Application Technology Working Group (WhatWG)，专注于 W3C 已经放弃的领域，而且与 W3C 背道而驰。
这一过程花费了两年时间，但是在 3 月份，W3C 终于意识到他们即将受到威胁。他们重新成立了自己的 HTML 工作组并玩起了追赶游戏。两大组织都同意分享利益，但是 WhatWG 仍然处于主导地位，并控制着整个市场。
尽管竞争激烈，2007 年并没有产生多少实用的 HTML 5 代码。规范开发主要集中在 Web 视频、SQL API，以及解析 arcana。将会在普通 Web 浏览器中实现哪种技术仍然是一个未知问题。对我个人而言，我怀疑在原生 XML 数据库在场外做热身时花费几个月时间开发一个浏览器内置的 SQL API 是不是明智之举(我答应这是本文中最后一次用足球做比喻，或者您可以拿走裁判员的口哨)。
4 月
尽管早就有传闻 XML 将在 Web 中引入语义并使浏览器能够理解其显示的内容，但 XML 始终是关于语法，而不是语义。整个 XML 1.0 规范只包含两个和语义沾边的属性：xml:space 和 xml:lang(而且我不能肯定 xml:space 是不是语义属性)。在很大程度上，XML 规范的意义来自于处理 XML 文档的应用程序，而不是文档本身。XML 系列的后续规范也几乎是这样，包括名称空间、XML Infoset、XSLT，以及 XPath。
但是在 4 月份，W3C 通过发布 Internationalization Tag Set (ITS) 1.0 进一步扩展了 xml:lang 属性。这个推荐标准定义了标识方向性、可译性、ruby 文本的标准属性和可跨不同词汇表共享的文档本地化和国际化的其他常见内容。例如，在清单 1 显示的 DocBook 文章中，its:translate 属性指示 author 元素不应该被翻译，而 its:dir 属性表明整个文档使用从左到右的文本。
清单 1. 带有 ITS 标记的 DocBook 文章
＜xforms:model＞＜dbk:article
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:dbk="http://docbook.org/ns/docbook"
its:version="1.0" version="5.0" xml:lang="en"
its:dir="ltr"＞
＜dbk:info＞
＜dbk:title＞Fun with XML＜/dbk:title＞
＜dbk:author its:translate="no"＞
＜dbk:personname＞
＜dbk:firstname＞Elliotte＜/dbk:firstname＞
＜dbk:surname＞Harold＜/dbk:surname＞
＜/dbk:personname＞
＜/dbk:author＞
＜/dbk:info＞
＜dbk:para＞XML rocks!＜/dbk:para＞
＜/dbk:article＞
此规范并未引起广泛关注，但它对在多种环境中进行发布的人(就目前而言，几乎包括所有人)来说非常有用。
在 4 月，W3C Internationalization Activity 还发布了国际化最佳实践的完结版：指定 XHTML 和 HTML 内容中的语言。我将该建议总结为 16 条 “最佳实践”：
最佳实践 1：总是使用 html 标记属性声明页面文本的默认语言，除非文档包含针对使用多种语言的演讲者的内容。
最佳实践 2：如果文档包含针对使用多种语言的演讲者的内容，决定是否需要在 html 标志中声明一种语言，或者不定义语言。
最佳实践 3：如果文档包含针对使用多种语言的演讲者的内容，尝试根据最可能使用的语言对文档进行划分，并为每部分声明合适的语言。
最佳实践 4：在文本中使用 lang 和/或 xml:lang 属性来指出语言上的任何更改。
最佳实践 5：对于 HTML，只使用 lang 属性;对于用作文本或 html 的 XHTML 1.0，使用 lang 和 xml:lang 属性;对于用作 XML 的 XHTML，只使用 xml:lang 属性。
最佳实践 6：使用语言属性声明用于文本处理的默认语言，而不是使用 HTTP 或元元素。
最佳实践 7：不要在 body 元素中声明文档的默认语言，使用 html 元素。
最佳实践 8：如果属性值中的文本和元素内容使用的语言不同，考虑使用嵌入式方法。
最佳实践 9：考虑在 HTTP 报头使用 Content-Language 声明或者使用元标记声明文档目标受众的语言元数据。
最佳实践 10：如果文档包含针对使用多种语言的演讲者的内容，结合使用 Content-Language 和以逗号分隔的语言标记列表。
最佳实践 11：遵循 IETF 的 BCP 47 中关于语言属性值的指导。
最佳实践 12：使用尽可能短的语言标记值。
最佳实践 13：如果可能，使用代码 zh-Hans 和 zh-Hant 分别指代简体中文和繁体中文。
最佳实践 14：当指向另一种语言中的资源时，考虑指明目标文档语言的优缺点。
最佳实践 15：如果希望指出一个元素的目标文档使用的是另一种语言，考虑结合使用 CSS 和 hreflang 的优缺点。
最佳实践 16：不要使用标志图标指明语言。
5 月
MathML 是最初的几个 XML 应用程序之一，但遗憾的是它的实际应用有限。尽管如此，W3C Math Working Group 并没有放弃，并在 4 月末发行了 MathML 3 的第一个草案(是的，我知道本节应该总结 5 月份的事件，但 5 月份并没有发生太多的 XML 事件)。
MathML 3 最重要的功能是支持小学数学符号。毕竟，小学生比数学博士多得多，比例大概是 100 000 比 1。MathML 3 还添加了对双向布局的支持，并针对改良的排版对断行和定位方法进行了改进。最后，经过重写之后的规范条理更加清晰。我们希望第 3 次修改会更好。毕竟，Web 是为数学而诞生的。
6 月
在 6 月，OpenOffice Project 发布了 OpenOffice 2.2，这是一个跨平台的 office 套件，它将所有文件保存为国际标准 OpenDoc 格式的压缩 XML 文件。这几乎是一个 bug 修复版，不值得在一篇年度回顾文章中提及。但真正值得一提的是 OpenOffice Project 在发布针对 Linux® 和 Microsoft® Windows® 的版本的同时，还发布了第一个原生 Mac OS X 版本。
与 Mac 上以前的不完全版本(semi-releases)不同，2.2 版基于 Mac 的原生 Aqua 用户接口工具箱，而不是 X-Windows。虽然 Mac 版本只具有内部测试版品质(alpha quality)，但仍然极大推动了 OpenOffice，使其离成为 Microsoft Office 有力竞争者这一目标更进一步。如果 OpenOffice 能够吸引大量使用 MacBook 的编程人员，那么它最终可能消除自 1.0 版就存在的用户界面问题。
6 月里也发生了与浏览器端相关的重大事件，Apple 在这一月发布了 Safari 3.0 for Windows 的第一个测试版。Apple 不再满足于 6%(仍在增长)的市场份额，它似乎要在大后方向 Microsoft 发起全面挑战。首先是 iTunes，现在是 Safari？iLife 和 iWork 还会很远吗？只有在 2008 年才能看到结果。同时，Safari 支持 XML、XSLT、Cascading Style Sheets (CSS)、XHTML、Atom 和 RSS。Safari 的 CSS 支持比任何其他 Windows 平台的浏览器都要好。由于被 Google 搞得心烦意乱，Microsoft 可能未注意到 Apple 已经从后面偷偷赶上了。
7 月
在 7 月，W3C 发布了 Efficient XML Interchange (EXI) Format 1.0 的第一个公开工作草案。该规范声明：
“EXI 是 eXtensible Markup Language (XML) Information Set 的简洁表示，旨在同时优化性能和计算资源的利用率。EXI 格式使用一种源于信息和正式语言理论的混合方法以及经过测量验证的实践技术对 XML 信息进行熵编码。使用相对简单的算法和一个小型的数据类型集合，前者有助于更快更紧凑的实现，后者能够可靠地产生有效的 XML 事件流编码”。
我不知道还有什么比这更糟：这种格式难以置信的不透明性，或者 EXI 实际上并不是 XML 信息集合表示的事实。不透明性我已经预料到了，但是后者大出我所料。EXI 引入了数据类型，比如二进制、布尔值、小数、浮点数、整数、无符号整数，以及日期-时间。XML 没有数据类型，而这只是一个特性，并不是一个 bug。XML 并未打算告诉任何读者它如何解释文档中的文本字符串，但 EXI 这样做了。
幸运的是，在年末，EXI 在 W3C 的其他成员中出现后退，其中包括著名的 Technical Architecture Group。W3C 流程很难改变规范的方向，无论该规范是多么的不完善，因此 EXI 很可能会在 2008 年发布。这并不是 W3C 孵化的第一个产物(某种模式？)，而且也肯定不是最后一个;但是如果对二进制序列化的固有问题进行充分的提前预警，那么就不会造成更多的损失。希望人们更多地将其看作 XML 1.1，而不是 XML Schema。
8 月
在 8 月，XML 研究者从法国转移到蒙特利尔，在这里举行了一年一次的 Extreme Markup Languages 会议。这是至今为止每年三次主要 XML 会议中最令人讨厌的一次。没有关于如何编写样式表或模式的培训。取而代之的是 “A Web 2.0 ANSI SQL Transparent Native XML Nonlinear Hierarchical LCA Query Processor” 和 “Exploring intertextual semantics: A reflection on attributes and optionality” 这样的主题。
这个会议总是经费紧张，发言者通常比付费的出席者要多。会议主办方往往在会议结束时才确定是否将再次举行会议，而每个人也在静观其变。很不幸，今年将不再举办此会议。2007 年注定是 Extreme 的最后一次争论(尽管它比许多竞争者都更长久)。
但是随着旧的会议的结束，新的会议将会出现。Mulberry Technologies，从我注意到它开始就在几乎所有内容上使用 Extreme，该组织宣布将于 2008 年 8 月 12-15 日在蒙特利尔举行 Balisage: The Markup Conference。
“Balisage 将会满足那些致力于满足拓宽标记应用领域的理论家或实践家的需要。所有内容都与标记相关：如何创建标记;标记的含义;分层与重叠;模拟;分类;转换;查询、搜索和检索;呈现和可访问性;构建能够使用标记的系统(或者使标记在更小的空间获得更快的性能)— 简而言之，通过对信息进行标记产生的强大功能改变世界和 Web。”
如果加拿大元继续与美元背道而驰，那么 2008 年对美国人来说不太划算，但对欧洲人和加拿大人确是个好时机。
9 月
本年度最大的事件发生在 9 月，借助对 Office Open XML 格式的支持，Microsoft 促成了 International Standards Organization (ISO) 各国成员的投票者注册活动。这次活动首先发生在瑞典，在瑞典，23 个主要的小型 Microsoft 附属公司在最后关头加入了瑞典标准协会(Swedish Standards Institute)，其中 22 个公司投票支持 OOXML。其他国家级标准机构也吸纳了比往年更多的会员应用程序，其中大多数来自 Microsoft 的合作伙伴。以前未加入 JTC 1/SC 34(ISO 的附属委员会，大多数 XML 工作都在这里完成)的国家突然之间都加入了。
尽管 Office Open XML 获得了大多数选票(51-18-18)，但它需要至少 2/3 的 “正式成员” 的支持，而且反对票不能多于 25%。这两个条件它都不满足，因此该规范被返回到 Ecma International 进行评议。也许 Microsoft 可以改进该规范，从而在 2 月的重新审议中获得所需的选票，但是结果还不能确定。撰写本文时，MIcrosoft 似乎不太愿意让 ISO 控制 OOXML 的改进，因此之前的一些赞成票可能会变成反对票。
为 OOXML 争取选票的努力也间接损害了一些其他不相关规范的利益，包括 Document Schema Definition Languages (DSDL)。许多支持 OOXML 的新成员对其他工作组任务不感兴趣。一旦他们投出选票后，他们将会消失，因而在决议无关的和争议较少的问题时无法达到法定人数。
10 月
Atom 发布协议在 10 月发布。APP 作为上传 blog 条目的简单格式登上了舞台，旨在取代像 MetaWeblog 和 WordPress API 这样的定制 API。但是，在这一过程中，APP 逐渐显示出越来越多的优势。
APP 只不过是一个用于将内容发布到 HTTP 服务器的具有 RESTf 风格的、可伸缩的、可扩展的安全系统。一方面，它是一个纯协议，完全独立于任何特定的服务器和客户机。另一方面，由于它也属于 HTTP，所以很容易在现有客户机和服务器上实现。
Web 最初只是作为一个读写媒介。但是在最初的 15 年里，主要的投入都放在了读取功能上。浏览器吸引了所有人的目光，而创建工具却没人关注。页面编辑器很少，而且主要通过 FTP 传递到文件系统。直到现在，借助 APP，编辑器才得以变得与浏览器一样丰富、功能强大且易于使用。
一些优秀的服务器软件(比如 eXist 原生 XML 数据库)已经开始使用 APP，而且一些客户机也正在使用它。在即将来临的一年里，将会有更多的软件采用 APP。在 Web 上发布内容将会变得与浏览内容一样简单。
11 月
在 11 月，Mark Logic 公开了 MarkMail，这是一个用于与电子邮件存档文件交互的基于 XQuery 的站点。Jason Hunter 这样描述它：
“每一封电子邮件都被存储为一个 XML 文档，并通过 XQuery 对其进行访问。所有的搜索、分面导航(faceted navigation)、分析计算，以及 HTML 页面呈现都是在一个单独的 MarkLogic Server 计算机上执行的”。
MarkMail 目前索引了大约 500 个邮件列表，包括 Apache 邮件列表、与 jdom 有关的邮件、xml-dev 等等。
自然地，人们使用此功能所做的第一件事就是搜索自己的知名度。在这个集合中，发贴最多的人(top human poster)一直都是 Saxon 届的名人 Michael Kay(一些自动发送提交消息的 Apache robots 试图超过他);但是在 xml-dev 方面，讨论最多的主题是 Len Bullard，有超过 4,000 封邮件与此相关。Len 的大多数邮件都包含好几页的文章，这使得他更加受关注。
我在 xml-dev 方面排名第 10，拥有 1,014 封邮件。要不是两年前我更换了邮件客户机，我可能会排在第 9 位。我的屏幕名称由 “Elliotte Rusty Harold” 更改为 “Elliotte Harold”，而数据库就把它们当作两个人来处理。系统中还有一些其他 bug。:-)
12 月
IDEAlliance 一年一度的 XML 2007 会议在 12 月初召开，这是本年度规模最大的一次 XML 展览。这次会议在波士顿举行。出席的人数有所减少，只有 300 余位与会者和 15 位展出者。
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）本次展出的大部分内容都是比较著名的技术，至少是中坚 XML 开发人员一直关注的技术。与去年一样，XQuery 仍然是展览会中的明星，尽管 XForms 也非常引人关注。XProc、RDFa、OpenDoc、Office Open XML、Atom、APP 和 JSON 也引起了不少人的关注。Web 服务和任何与 SOAP 相关的技术的缺席惹人注意。除了 “但是现在我们正转向 REST” 以外，我还没有听见过这方面的术语。
展览会上真正的新产品来自预料以外的厂家：Intel。尽管 Intel 在硬件方面更著名，但是它也开发能最大限度利用自己的处理器的软件。Intel 在展会上展出并发布了 Intel XML Software Suite，这是一个针对 Linux 和 Windows 的原生 X86 库的集合，提供了真正的快速 XSLT 处理、XPath 评估、XML 模式验证、文档对象模型(DOM)，以及 Simple API for XML (SAX) 解析。其中还包括一个基于 Java 原生接口(Java Native Interface，JNI)的针对 Java™ 平台的包装器。
Intel 声称这个库的速度是 XPath 和 XSLT 的 XSLTC 和 Xalan 的两倍，而且比对大型(大于 100MB)文档进行原始解析的 Xerces-C++ 快 6 倍。解析器使用占用更少内存的符号表数据结构和跨两个或更多内核的多线程处理来实现这些性能。这个库可用于处理 300 MB 到 32 GB 范围的文档。对于更小的文档，由于这项技术开销比较大，所以传统解析器更快些。
我还没有机会验证 Intel 的宣称;但是如果这是真的，将非常有趣。Xerces 并不是最快的解析器，但是 6 倍的速度提升是其他任何技术都还未达到的。令人惊讶的是，Intel 使用标准 API、SAX 和 DOM 达到了这样的性能。对我个人而言，我非常相信 XML 解析性能能够提升，但是我以前以为需要专注于高性能的新 API 来实现。Intel 似乎不需要这样做。
W3C 工作组通常在 12 月完成预期的工作，并在圣诞节之前发布规范。对 W3C 来说，圣诞节前一周通常是一年中最忙的时间。请关注 http://www.w3.org/TR/，也许还有更多惊喜等着您。:-)
结束语
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）对于 XML 来说，2007 年是多产的一年。主要的争论集中在 office 文档的标准化方面，这场战斗甚至引起了流行刊物的关注(有谁曾经在 Wall Street Journal 上阅读过关于 XML 格式的 ISO 标准的信息呢？)
但是如果我不得不挑选出今年发生的最重要的事件，我很难在正在缓慢成长的 XQuery、APP 和 XForms 之间做出选择。所有这些都有可能从根本上改变 Web 的底层软件基础结构。XForms 是一个全新的客户机开发平台，XQuery 是一个全新的服务器开发平台，而 APP 将二者连接起来。在三者当中，XQuery 已能够应用于生产，而 APP 正在快速发展。在 2008 年，两者之间一定会发生重大事件。XForms 紧跟其后，也许稍微有点落后，但是我希望它的发展不算太慢。总之，XML 在 Web 上的前景要比以前更加光明。
