介紹
2001 年 7 月 9 日，W3C 宣布發布 XML 協議工作組（WC）的兩個工作草案文檔。該工作組發布了 SOAP 規范版本 1.2 和 XML 協議抽象模型文檔的最新版本。
這次對 SOAP 規范的更新明確了含義模糊的內容，並簡化了實現之間的互操作性問題，與此同時還關注著現有實現的向後兼容。雖然工作組為 SOAP 的演化采取了一些積極措施，但工作重點仍集中在澄清問題上。熟悉 SOAP 規范的 1.1 版本的人應該會對最新版本一見如故。抽象模型文檔旨在提供一套 SOAP 規范的讀者們能夠使用的通用術語和概念。雖然抽象模型文檔並沒有提供實現 SOAP 處理器的設計，但是它確實使大家對於規范的制定者們如何預見 SOAP 處理器的不同組件之間的協同工作有了深入的了解。
隨著這些文檔的發布，現在似乎已是對工作組最近的一些活動、問題以及決定做一個簡單概括的最佳時機了。然而，這一概述肯定無法做到面面俱到，並且當然會偏向我認為值得注意的方面。因此，我在本文的結尾處提供了更多的詳細參考資料的鏈接。
發布會開始時，我們在法國 Dinard 舉行了一次由 Cannon 主持的面對面的（F2F）會議。如我們所願，會議中所取得的進展要比僅僅使用電子郵件地址和電話交流取得的進展大得多。其中最明顯的決策之一就是關於該協議的名稱。最終的決定是：由於首字母縮寫詞“SOAP”在業界得到廣泛認可，所以我們不想把它的名稱改為其它相對不知名的詞匯 — 如 XML 協議。一旦決定保留名稱“SOAP”，問題就成了我們是否希望 SOAP 仍舊代表簡單對象訪問協議（Simple Object Access Protocol）。因此我們投票決定，“SOAP”不應再作為一個縮寫詞，而應該就是 SOAP 本身，如今其字母背後也不再有特殊意義。
逐步了解
在 F2F 會議中所作出的更為重要的決定之一，從實現者的角度來看，是關於 SOAP 處理模型的決定。在 SOAP 原來的版本中，有一點不甚明確，那就是在進行過程中執行 MustUnderstand （MU）檢查時，每個頭部分是否都能以特定的順序得以處理，或者所有這些 MU 檢查是否必須在處理余下的每個頭部分之前執行。工作組決定，一個 SOAP 處理節點必須向其它 SOAP 節點顯示在它處理任何一個頭部分之前已經執行了所有的 MU 檢查。因此，如果某一次實現選擇在 SOAP 消息流入的時候對其進行處理，並在處理每個頭部分的同時進行 MU 檢查，那麼該實現必須支持一些 取消（undo）的概念。所以，如果在處理過程中出現了 MU 錯誤，那麼它應該沒有先前處理過的頭部分遺留下的副作用。用來說明這個“無副作用”處理方法的最好的例子（雖然有些不正常）如 清單 1所示。
清單 1：流式消息的無副作用應用
<env:Header XMLns:env="http://www.w3.org/2001/06/soap-envelope">
<c:fireNuke XMLns:c="http://us.gov/potus" env:MustUnderstand="1"/>
<c:getAuthorization XMLns:c="http://us.gov/potus" env:MustUnderstand="1"/>
</env>
從該示例中可以清楚地看到，如果我們允許在 SOAP 處理器驗證了 fireNuke 頭部分已理解 getAuthorization 頭部分的語義之前就對它進行處理，那麼就可能最終得到一些不願看到的結果。
工作組以 MustUnderstand 為主題，作了另外一個關於返回 MU 出錯消息的關鍵決策。那就是開發了一種標准的選錯機制，一旦出現未被理解的 MU 頭部分，返回的錯誤就將遵循某種格式 — 使得對於這些錯誤的程序性分析容易不少。基本思想是，在 MU 錯誤中有一個定義完好的頭部分，它包含了一份所有未被理解的 MU 頭部分的列表。例如，如果上述示例中的 getAuthorization 頭部分未被理解，那麼 MU 錯誤中就應該出現如 清單 2中所示的頭部分。
清單 2：MU 錯誤的可選擇性頭部分
<env:Header XMLns:env="http://www.w3.org/2001/06/soap-envelope">
<f:Misunderstood qname="c:getAuthorization" XMLns:c="http://us.gov/potus/"
XMLns:f='http://www.w3.org/2001/06/soap-faults' >
</env>
采取行動
最近討論的一些有較大爭議的問題之一就是 SOAPAction HTTP 頭部分的問題。就 SOAPAction HTTP 頭部分當前的形式來說，一個被普遍（但並非一致）認同的觀點是它的使用和定義有些模糊。規范中僅僅說它應包含消息的 意圖，並且只針對 HTTP 作了定義。對於在其它傳輸中該做些什麼、如何處理在傳輸（HTTP 是其中之一）之間移動 SOAP 消息的情況，以及“意圖”的含義（它是否用作路由？它是不是目標服務？）則未作規定。簡言之，就是一些人想保留它，而另一些人想除去它。我們最終確定了兩個建議，並將它們提交對提議持歡迎態度的 SOAP 社區：
不鼓勵使用 SOAPAction。SOAPAction 是 SOAP 的可選部件，它受支持，但並不必要。服務中“也許”會需要 SOAPAction，並且任何想要訪問哪些服務的軟件都“必須”能夠發送它。
反對使用 SOAPAction。發送方“不應該”發送 SOAPAction。接收方“不許”在 SOAPAction 頭部分存在、不存在或它的值的基礎上接受或拒絕接受消息。
在 F2F 會議中，我們的確對此進行了非正式投票，結果是 22 票支持，4 票反對 — 未得到一致通過。SOAP 社區本身非常真實地反映了工作組的立場（也未一致通過），因此該問題依然存在。
名稱空間中的內容
有一點是意料之中的，即新的 SOAP 版本還將有新的名稱空間。目前，新的名稱空間為 http://www.w3.org/2001/06/soap-envelope 。
多少由於新的名稱空間的關系，同時還開發了一個新版本的錯誤模型。基本思想是，當一個 SOAP 處理節點接收到帶有它不支持的名稱空間的 SOAP 消息時，它必須返回一個帶有舊的 SOAP 1.1 名稱空間（ http://schemas.XMLsoap.org/soap/envelope ）的 VersionMismatch 錯誤，並且應該包括一個包含受支持的 SOAP 名稱空間列表的 Upgrade 頭部分。例如，如果一個 SOAP 1.2 處理節點接收到一個 SOAP 1.1 消息卻無法處理，因為它不支持 SOAP 1.1 語義，那麼它就應該返回如 清單 3所示的出錯消息。
清單 3：SOAP 1.2 與 1.1 請求不匹配的出錯消息
<env:Envelope xmlns:env="http://schemas.XMLsoap.org/soap/envelope/">
<env:Header>
<V:Upgrade XMLns:V="http://www.w3.org/2001/06/soap-upgrade">
<envelope qname="ns1:Envelope"
XMLns:ns1="http://www.w3.org/2001/06/soap-envelope"/>
</V:Upgrade>
</env:Header>
<env:Body>
<env:Fault>
<faultcode>env:VersionMismatch</faultcode>
<faultstring>Version Mismatch</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
使用 XML infoset
近來，關於 infoset 的課題被提了出來。Infoset 是這樣一個機制，通過它，不必使用空白、尖括號以及單、雙引號等瑣碎的細節符號就能描述 XML 文檔。它允許對包含在 XML 中的實際數據而不是 XML 的特定格式進行更為抽象的討論。這一機制的一種令人感興趣的用途，就是它使新的 XML 格式（比如擁有更簡潔的句法的二進制 XML）的出現成為了可能。在調查 Infoset 及其在 SOAP 規范中可能的用途的過程中，Martin Gudgin 根據 XML infoset 重寫了規范的第 4 部分。因此，從 Martin 所完成的工作中抽取一個片斷來看，一個 Infoset 定義的頭部分元素示例可能包含以下內容：
頭部分的本地名稱
“http://www.w3.org/2001/06/soap-envelope/”的名稱空間名稱
零或更多個符合名稱空間條件的屬性信息項目（Attribute Information Items）
零或更多個符合名稱空間條件的元素信息子項目（Element Information Item children）。
請注意，它是如何將重點集中在包含在 XML 中的實際數據上，而非數據的特定文本格式上的。在更高層次上，比如，在關於如何定義一種特定傳輸上的 SOAP 的定義中，其注意力就在於 XML 的實際物質表現的特定細節發生之處。
同樣值得注意的還有讓數據類型 boolean 接受 0、1、ture 和 false（“0”為 MU 頭部分中的缺省值）的決定。
繼續下一項任務
XML 協議組現在有兩個新的下屬機構：傳輸綁定任務組（Transport Binding Task Force）和 RPC 任務組（RPC Task Force）。這兩個任務組的目標主要是決定涉及各個課題的 SOAP 規范的語法和語義。傳輸綁定任務組關於最基本的問題（諸如“什麼是綁定？”這樣基本的問題）已經有了不少討論。如果您對其中的任何課題感興趣的話，我建議您浏覽一遍郵件列表文檔，並查看一下該工作小組的 Web 頁。讓我來對如此廣泛多樣的選項作總結可能反而會對原意造成不可思議的損害。那麼我們暫且假設它涉及的不同觀點相當多。RPC 任務組剛剛成立，現仍處於收集問題的階段。
還有些什麼？除了本文中提到的問題以外，XML 工作組的面前還擺著不少尚待解決的問題。想獲得詳盡的列表，請參閱問題列表。一些更為活躍的問題（如 SOAPAction）肯定會讓您興奮的。對於任何對 SOAP 感興趣的人，無論是技術的熱衷者還是實現者，我都建議您通過訂閱並加入 XML-dist-app 郵件列表來留意工作組的發展。該工作組在一個方面是非常獨特的，那就是：它大概是 W3C 工作組中最開放的一個了 — 我們的所有工作幾乎都是以一種開放、公共的方式完成的，並且 SOAP 社區的參與、意見和反饋都是其工作得以成功的關鍵因素。
作者的免責聲明：對於本文中提及的任何、或所有決策，都應視為工作組在當前時刻想法的快照。有相當多的人急切希望工作組完成其工作，因此可能會根據工作組的臨時決策做出實現的選擇，這是可以理解的，但請注意，工作組如今所作出的決策可能會在日後有所改變。