對 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在 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 位展出者。
本次展出的大部分內容都是比較著名的技術，至少是中堅 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/，也許還有更多驚喜等著您。:-)
結束語
對於 XML 來說，2007 年是多產的一年。主要的爭論集中在 Office 文檔的標准化方面，這場戰斗甚至引起了流行刊物的關注(有誰曾經在 Wall Street Journal 上閱讀過關於 XML 格式的 ISO 標准的信息呢?)
但是如果我不得不挑選出今年發生的最重要的事件，我很難在正在緩慢成長的 XQuery、APP 和 XForms 之間做出選擇。所有這些都有可能從根本上改變 Web 的底層軟件基礎結構。XForms 是一個全新的客戶機開發平台，XQuery 是一個全新的服務器開發平台，而 APP 將二者連接起來。在三者當中，XQuery 已能夠應用於生產，而 APP 正在快速發展。在 2008 年，兩者之間一定會發生重大事件。XForms 緊跟其後，也許稍微有點落後，但是我希望它的發展不算太慢。總之，XML 在 Web 上的前景要比以前更加光明。