本節(jié)描述了如何在使用或不使用HTTP Extension Framework的前提下將SOAP與HTTP的協同工作機制。將SOAP綁定在HTTP上可以利用HTTP豐富的特性集，提供使用SOAP形式方法和分布適應性的優(yōu)點。將SOAP在HTTP上傳輸并不以為著SOAP可以完全超越HTTP的語義，更恰當的描述應當是SOAP的語義通過HTTP的映射而很自然地成為HTTP的語義。

SOAP很自然地利用HTTP的請求/響應消息模型，將SOAP請求的參數放在HTTP請求里，而將SOAP響應的參數放在HTTP響應里面。注意，無論如何，SOAP的中間介與HTTP中間介是不同的。也就是說，根據HTTP Connection頭字段來尋址的HTTP中間介一般并不能來處理HTTP請求中的SOAP實體體。

當需要將SOAP消息體包含在HTTP消息中時，HTTP應用程序必須依照RFC2376[3]使用媒體類型“text/xml”。

6.1 SOAP HTTP請求

雖然SOAP可以和多種HTTP請求方法聯合使用，但這里的綁定只定義了SOAP是如何在HTTP Post請求中傳輸的。(可參閱section 7了解如何在RPC中使用SOAP，以及section 6.3如何使用HTTP Extension Framework)

6.1.1 HTTP Header中的SOAPAction字段

SOAPAction HTTP請求頭字段(header field)可以用于指示SOAP HTTP請求的目的。它的值是一個標識該目的的URI。SOAP對于格式上并沒有嚴格的限制，同時對URI的描述以及是否要是可解析的都沒有嚴格的限制。當發(fā)出SOAP HTTP請求時，HTTP客戶必須使用該頭字段。

soapaction
=
"SOAPAction" ":" [ <"> URI-reference <"> ]

URI-reference
=
<as defined in RFC 2396 [4]>

SOAPAction頭字段的存在及其內容可以被服務器例如防火墻用于在HTTP中過濾SOAP請求消息。當該字段的值為空字符串( “”)時，則意味著SOAP消息的目的由HTTP Request-URI來提供。而如果沒有值則表示對消息的目的沒有指示。

例如:

Example 42

SOAPAction: "http://electrocommerce.org/abc#MyMessage"SOAPAction: "myapp.sdl"SOAPAction: ""SOAPAction:

Examples of values for SOAPAction

6.2 SOAP HTTP響應

在HTTP之上的SOAP遵從用于在HTTP中表示通訊狀態(tài)的HTTP狀態(tài)代碼的語義。例如，2xx狀態(tài)代碼表明這是客戶端包含SOAP構件的請求被成功的接收、理解和接受等等。

當處理請求的時候發(fā)生SOAP錯誤的時候，SOAP HTTP服務器必須發(fā)出一個HTTP 500 “Internal Server Error”響應同時在包含于該響應的SOAP消息中應包含一個SOAP Fault元素(參閱 section 4.4)來指明SOAP處理的錯誤。

6.3 HTTP擴展框架

SOAP消息可以與HTTP Extension Framework[6]一起使用來標識SOAP HTTP請求的出現和意圖。

是使用Extension Framework還是使用簡單HTTP對于通訊各方而言是一個策略及能力的問題?？蛻舳丝梢酝ㄟ^一個強制擴展聲明以及一個“M-”HTTP方法名前綴來強制使用HTTP Extension Framwork。服務器端可以通過使用 510 “Not Extended” HTTP狀態(tài)代碼來強制使用HTTP Extension Framework。也就是說，通過一次額外的環(huán)游，每個通訊方都可以檢測到其他通訊方和因此的動作。

用于使用Extension Framework標識SOAP的擴展標識是:

http://www.w3.org/2001/06/soap-envelope

6.4 SOAP HTTP示例

Example 43

POST /StockQuote HTTP/1.1Content-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "http://electrocommerce.org/abc#MyMessage"<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

SOAP HTTP Request Using POST

Example 44

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

SOAP HTTP Response to Example 43

Example 45

M-POST /StockQuote HTTP/1.1Man: "http://www.w3.org/2001/06/soap-envelope"; ns=NNNNContent-Type: text/xml; charset="utf-8"Content-Length: nnnnNNNN-SOAPAction: "http://electrocommerce.org/abc#MyMessage"<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

SOAP HTTP Request using the experimental HTTP Extension Framework

Example 46

HTTP/1.1 200 OKExt:Content-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

SOAP HTTP Response to Example 45

7. 在RPC中使用SOAP

SOAP的一個設計目標就是要利用XML的可擴展性和可伸縮性來包裝和交換RPC調用。本節(jié)定義了一個統(tǒng)一的遠程過程調用和響應的表示。

其實我們也可以預想到在RPC環(huán)境下的表示很可能是與在其他表示中定義的編碼風格結合。SOAP encodingStyle屬性(參閱 section 4.3.2)可以被用于指明在本節(jié)表示中使用的方法調用/響應的編碼風格。

在RPC中使用SOAP與SOAP協議綁定(參閱 section 6)基本是正交的。在使用HTTP作為SOAP協議綁定媒介的情況下，一個RPC調用可以很自然地映射到一個HTTP請求，而RPC響應則可以映射到HTTP響應。無論如何，使用SOAP方式的RPC并不限于HTTP協議綁定。

為實施一個方法調用，需要以下信息:

目標SOAP結點的URI

方法名

可選的方法或過程的特征

方法或過程的參數

可選的頭數據

SOAP依賴協議綁定來提供傳送URI的機制。例如，對HTTP而言，請求URI指明了與該調用相對應的資源。除要求該URI是合法的以外，SOAP對于該地址沒有任何限制(參閱[4]以獲得URI的更多信息)。

7.1 RPC和SOAP Body

RPC調用和響應都是在SOAP Body元素(參閱 section 4.3)中傳送，使用如下表示方式:

一個方法調用被建模成一個結構struct。

該方法調用顯示為一個簡單結構struct，包含每個[in]或[in/out]參數的存取標識。該結構的名和類型可使用過程或方法的名來標識。

每個[in]或[in/out]參數都被表示為一個存取標識，該存取標識的名和類型都對應于相應參數的名和類型。他們的次序也是按照原來RPC中的次序。

一個方法響應被建模成一個結構struct。

該方法響應顯示為一個簡單結構struct，包含每個[out]或[in/out]參數的存取標識。而第一個存取標識是返回值，而隨后則是按照原來次序的返回參數。

每個[out]或[in/out]參數都被表示為一個存取標識，該存取標識的名和類型都對應于相應參數的名和類型。返回值的存取標識名并沒有多少語義。同樣的，結構的名也并沒有多少語義。當然，無論如何，在添加了“Response”字串的方法名后，要有一個約定來命名它。

方法調用出錯應使用SOAP Fault元素來編碼(餐飲 section 4.4)。如果一個綁定協議對于錯誤表達還有額外規(guī)則，那么這些規(guī)則都應當被遵守。

就象先前表述的那樣，方法和響應的結構可以使用在section 5中定義的規(guī)則來編碼，也可以使用在encodingStyle屬性中描述的其他編碼(參閱 section 4.1.1)。

應用程序可以處理漏寫參數的請求不過也可以返回一個錯誤。

因為在響應中若包含“result”則表明成功，若包含“fault”則表明失敗，所以如果方法響應中同時包含了“result”和“fault”則是錯誤的。

7.2 RPC和SOAP Header

對于那些并非是方法的正式調用數據部分，而是方法請求編碼相關的一些額外信息，也可以在RPC編碼中表示。如果這樣，它必須作為SOAP Header元素的一個子元素來描述。

對于使用header元素的一個例子是在消息中傳送一個事務ID。事務ID并不是調用參數表中的一員，它一般是要被下層構件所處理而不僅僅是一個應用程序ID，而這里并沒有一個直接的方法在調用中傳送這一需要的信息。通過在頭上加一個條目并賦予它一個固定的名字，接收方的事務管理器就可以將該事務ID抽取出來，同時就可以在不影響遠程過程調用的代碼的前提下使用它。

8. 安全機制的考慮

在本文檔中并不包含完整性和私密性保護的方法的描述。這些問題將在本文檔的以后版本中詳細說明。

9. 參考文獻

9.1. Normative references

[2] IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt

[3] IETF "RFC 2376: XML Media Types", E. Whitehead, M. Murata, July 1998. Available at http://www.ietf.org/rfc/rfc2376.txt

[4] IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt

[5] IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. Available at http://www.ietf.org/rfc/rfc2616.txt

[6] IETF "RFC 2774: An HTTP Extension Framework", H. Nielsen, P. Leach, S. Lawrence, February 2000. Available at http://www.ietf.org/rfc/rfc2774.txt

[7] W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. Available at http://www.w3.org/TR/2000/REC-xml-20001006

[8] W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. Available at http://www.w3.org/TR/1999/REC-xml-names-19990114/

[9] W3C Proposed Recommendation "XML Linking Language (XLink) Version 1.0", Steve DeRose, Eve Maler, David Orchard, 20 December 2000. Available at http://www.w3.org/TR/2000/PR-xlink-20001220/

[10] W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

[11] W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

9.2. Informative references

[12] Transfer Syntax NDR, in Open Group Technical Standard "DCE 1.1: Remote Procedure Call", August 1997. Available at http://www.opengroup.org/public/pubs/catalog/c706.htm

[13] IETF "RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt

A. SOAP Envelope Examples

A.1 Sample Encoding of Call Requests

Example 47

POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "http://example.org/2001/06/quotes"<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > <env:Header> <t:Transaction xmlns:t="http://example.org/2001/06/tx" env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" env:mustUnderstand="1" > 5 </t:Transaction> </env:Header> <env:Body > <m:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes" > <m:symbol>DEF</m:symbol> </m:GetLastTradePrice> </env:Body></env:Envelope>

Similar to Example 1 but with a Mandatory Header

Example 48

POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "http://example.org/2001/06/quotes"<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > <env:Body> <m:GetLastTradePriceDetailed env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes" > <Symbol>DEF</Symbol> <Company>DEF Corp</Company> <Price>34.1</Price> </m:GetLastTradePriceDetailed> </env:Body></env:Envelope>

Similar to Example 1 but with multiple request parameters

A.2 Sample Encoding of Response

Example 49

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > <env:Header> <t:Transaction xmlns:t="http://example.org/2001/06/tx" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:int" env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" env:mustUnderstand="1" > 5 </t:Transaction> </env:Header> <env:Body> <m:GetLastTradePriceResponse env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes" > <Price>34.5</Price> </m:GetLastTradePriceResponse> </env:Body></env:Envelope>

Similar to Example 2 but with a Mandatory Header

Example 50

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > <env:Body> <m:GetLastTradePriceResponse env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes" > <PriceAndVolume> <LastTradePrice>34.5</LastTradePrice> <DayVolume>10000</DayVolume> </PriceAndVolume> </m:GetLastTradePriceResponse> </env:Body></env:Envelope>

Similar to Example 2 but with a Struct

Example 51

HTTP/1.1 500 Internal Server ErrorContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope"> <env:Body> <env:Fault> <faultcode>env:MustUnderstand</faultcode> <faultstring>SOAP Must Understand Error</faultstring> </env:Fault> </env:Body></env:Envelope>

Similar to Example 2 but Failing to honor Mandatory Header

Example 52

HTTP/1.1 500 Internal Server ErrorContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > <env:Body> <env:Fault> <faultcode>env:Server</faultcode> <faultstring>Server Error</faultstring> <detail> <e:myfaultdetails xmlns:e="http://example.org/2001/06/faults" > <message>My application didn't work</message> <errorcode>1001</errorcode> </e:myfaultdetails> </detail> </env:Fault> </env:Body></env:Envelope>

Similar to Example 2 but Failing to handle Body

B. Acknowledgements

This document is the work of the W3C XML Protocol Working Group.

Members of the Working Group are (at the time of writing, and by alphabetical order): Yasser al Safadi (Philips Research), Vidur Apparao (Netscape), Don Box (DevelopMentor), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Clay (Oracle), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel (Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Brian Eisenberg (Data Channel), David Ezell (Hewlett-Packard), James Falek (TIBCO Software, Inc.), David Fallside (IBM), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Martin Gudgin (Develop Mentor), Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale (Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Software Corporation), Murali Janakiraman (Rogue Wave), Mario Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (IDOOX s.r.o.), Alan Kropp (Epicentric), Yves Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Richard Martin (Active Data Exchange), Noah Mendelsohn (Lotus Development), Nilo Mitra (Ericsson Research Canada), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Software Corporation), Mark Needleman (Data Research Associates), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), Mark Nottingham (Akamai Technologies), David Orchard (JamCracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (Daimler-Chrysler Research and Technology), Hervé Ruellan (Canon), Marwan Sabbouh (MITRE Corporation), Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.), Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Randy Waldrop (WebMethods), Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research) and Dick Brooks (Group 8760). Previous members were: Eric Fedok (Active Data Exchange) Susan Yee (Active Data Exchange) Alex Milowski (Lexica), Bill Anderson (Xerox), Ed Mooney (Sun Microsystems), Mary Holstege (Calico Commerce), Rekha Nagarajan (Calico Commerce), John Evdemon (XML Solutions), Kevin Mitchell (XML Solutions), Yan Xu (DataChannel) Mike Dierken (DataChannel) Julian Kumar (Epicentric) Miles Chaston (Epicentric) Bjoern Heckel (Epicentric) Dean Moses (Epicentric) Michael Freeman (Engenia Software) Jim Hughes (Fujitsu Software Corporation) Francisco Cubera (IBM), Murray Maloney (Commerce One), Krishna Sankar (Cisco), Steve Hole (MessagingDirect Ltd.) John-Paul Sicotte (MessagingDirect Ltd.) Vilhelm Rosenqvist (NCR) Lew Shannon (NCR) Henry Lowe (OMG) Jim Trezzo (Oracle) Peter Lecuyer (Progress Software) Andrew Eisenberg (Progress Software) David Cleary (Progress Software) George Scott (Tradia Inc.) Erin Hoffman (Tradia Inc.) Conleth O'Connell (Vignette) Waqar Sadiq (Vitria Technology Inc.) Tom Breuel (Xerox) David Webber (XMLGlobal Technologies) Matthew MacKenzie (XMLGlobal Technologies) and Mark Baker (Sun Microsystems).

This document is based on the SOAP/1.1 specification whose authors were: Don Box (Develop Mentor), David Ehnebuske (IBM), Gopal Kakivaya (Microsoft Corp.), Andrew Layman (Microsoft Corp.) Noah Mendelsohn (Lotus Development Corp.), Henrik Frystyk Nielsen (Microsoft Corp.), Satish Thatte (Microsoft Corp.) and Dave Winer (UserLand Software, Inc.).

We also wish to thank all the people who have contributed to discussions on xml-dist-app@w3.org.

C. Version Transition From SOAP/1.1 to SOAP Version 1.2

EdNote: The scope of the mechanism provided in this section is for transition between SOAP/1.1 and SOAP version 1.2. The Working Group is considering providing a more general transition mechanism that can apply to any version. Such a general mechanism may or may not be the mechanism provided here depending on whether it is deemed applicable.

The SOAP/1.1 specification says the following on versioning in section 4.1.2:

"SOAP does not define a traditional versioning model based on major and minor version numbers. A SOAP message MUST have an Envelope element associated with the "http://schemas.xmlsoap.org/soap/envelope/" namespace. If a message is received by a SOAP application in which the SOAP Envelope element is associated with a different namespace, the application MUST treat this as a version error and discard the message. If the message is received through a request/response protocol such as HTTP, the application MUST respond with a SOAP VersionMismatch faultcode message (see section 4.4) using the SOAP "http://schemas.xmlsoap.org/soap/envelope/" namespace."

That is, rather than a versioning model based on shortnames (typically version numbers), SOAP uses a declarative extension model which allows a sender to include the desired features within the SOAP envelope construct. SOAP says nothing about the granularity of extensions nor how extensions may or may not affect the basic SOAP processing model. It is entirely up to extension designers be it either in a central or a decentralized manner to determine which features become SOAP extensions.

The SOAP extensibility model is based on the following four basic assumptions:

SOAP versioning is directed only at the SOAP envelope. It explicitly does not address versioning of blocks, encodings, protocol bindings, or otherwise.

A SOAP node must determine whether it supports the version of a SOAP message on a per message basis. In the following, "support" means understanding the semantics of the envelope version identified by the QName of the Envelope element:

A SOAP node receiving an envelope that it doesn't support must not attempt to process the message according to any other processing rules regardless of other up- or downstream SOAP nodes.

A SOAP node may provide support for multiple envelope versions. However, when processing a message a SOAP node must use the semantics defined by the version of that message.

It is essential that the envelope remains stable over time and that new features are added using the SOAP extensibility mechanism. Changing the envelope inherently affects interoperability, adds complexity, and requires central control of extensions -- all of which directly conflicts with the SOAP requirements.

No versioning model or extensibility model can prevent buggy implementations. Even though significant work has been going into clarifying the SOAP processing model, there is no guarantee that a SOAP 1.2 implementation will behave correctly. Only extensive testing within the SOAP community and design simplicity at the core can help prevent/catch bugs.

The rules for dealing with the possible SOAP/1.1 and SOAP Version 1.2 interactions are as follows:

Because of the SOAP/1.1 rules, a compliant SOAP/1.1 node receiving a SOAP Version 1.2 message will generate a VersionMismatch SOAP fault using an envelope qualified by the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier.

A SOAP Version 1.2 node receiving a SOAP/1.1 message may either process the message as SOAP/1.1 or generate a SOAP VersionMismatch fault using the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier. As part of the SOAP VersionMismatch fault, a SOAP Version 1.2 node should include the list of envelope versions that it supports using the SOAP upgrade extension identified by the "http://www.w3.org/2001/06/soap-upgrade" identifier.

The upgrade extension contains an ordered list of namespace identifiers of SOAP envelopes that the SOAP node supports in the order most to least preferred. Following is an example of a VersionMismatch fault generated by a SOAP Version 1.2 node including the SOAP upgrade extension:

Example 53

<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>

VersionMismatch fault generated by a SOAP Version 1.2 node, and including a SOAP upgrade extension

Note that existing SOAP/1.1 nodes are not likely to indicate which envelope versions they support. If nothing is indicated then this means that SOAP/1.1 is the only supported envelope.

D. Change Log

D.1 SOAP Specification Changes

Date
Author
Description

20010629
MJG
Amended description of routing and intermediaries in Section 2.1

20010629
JJM
Changed "latest version" URI to end with soap12

20010629
JJM
Remove "previous version" URI

20010629
JJM
Removed "Editor copy" in <title>

20010629
JJM
Removed "Editor copy" in the title.

20010629
JJM
Added "Previous version" to either point to SOAP/1.1, or explicitly mention there was no prior draft.

20010629
JJM
Pre-filed publication URIs.

20010629
JJM
Incorporated David's suggested changes for the examples in section 4.1.1 to 4.4.2

20010629
JJM
Fixed some remaining typos.

20010629
MJH
Fixed a couple of typos.

20010628
MJG
Made various formatting, spelling and grammatical fixes.

20010628
MJG
Moved soap:encodingStyle from soap:Envelope to children of soap:Header/soap:Body in examples 1, 2, 47, 48, 49 and 50

20010628
MJG
Changed text in Section 2.1 from 'it is both a SOAP sender or a SOAP receiver' to 'it is both a SOAP sender and a SOAP receiver'

20010628
MJG
Fixed caption on Example 24

20010628
MJH
Fixed a couple of capitalisation errors where the letter A appeared as a capital in the middle of a sentence.

20010628
MJH
Updated figure 1, removed ednote to do so.

20010622
HFN
Removed the introductory text in terminology section 1.4.3 as it talks about model stuff that is covered in section 2. It was left over from original glossary which also explained the SOAP model.

20010622
HFN
Moved the definition of block to encapsulation section in terminology

20010622
HFN
Removed introductory section in 1.4.1 as this overlaps with the model description in section 2 and doesn't belong in a terminology section

20010622
HFN
Removed reference to "Web Characterization Terminology & Definitions Sheet" in terminology section as this is not an active WD

20010622
HFN
Added revised glossary

20010622
HFN
Added example 0 to section 1.3 and slightly modified text for example 1 and 2 to make it clear that HTTP is used as a protocol binding

20010622
MJG
Added http://example.com/... to list of application/context specific URIs in section 1.2

20010622
MJG
Updated examples in section 4.1.1 to be encodingStyle attributes rather than just the values of attributes

20010622
MJG
Added table.norm, td.normitem and td.normtext styles to stylesheet. Used said styles for table of fault code values in section 4.4.1

20010622
MJG
In Appendix C, changed upgrade element to Upgrade and env to envelope. Made envelope unqualified. Updated schema document to match.

20010622
MJG
Moved MisunderstoodHeader from envelope schema into seperate faults schema. Removed entry in envelope schema change table in Appendix D.2 that refered to additon of said element. Modified example in section 4.4.2 to match. Added reference to schema document to section 4.4.2

20010622
MJH
Added binding as a component of SOAP in introduction. Fixed a couple of typos and updated a couple of example captions.

20010622
MJG
Made BNF in section 6.1.1 into a table.

20010622
MJG
Made BNFs in section 5.1 clause 8 into tables. Added associated 'bnf' style for table and td elements to stylesheet

20010622
MJG
Amended text regarding namespace prefix mappings in section 1.2

20010622
MJG
Added link to schema for the http://www.w3.org/2001/06/soap-upgrade namespace to Appendix C. Updated associated ednote.

20010622
MJG
Added reference numbers for XML Schema Recommendation to text prior to schema change tables in Appendix D.2 and linked said numbers to local references in this document

20010622
MJG
Reordered entries in schema change classification table in Appendix D.2

20010622
MJG
Changed type of mustUnderstand and root attributes to standard boolean and updated schema change tables in Appendix D.2 accordingly

20010622
JJM
Manually numbered all the examples (53 in total!)

20010622
JJM
Added caption text to all the examples

20010622
JJM
Replaced remaining occurrences of SOAP/1.2 with SOAP Version 1.2 (including <title>)

20010621
HFN
Added ednote to section 4.2.2 and 4.2.3 that we know they have to be incorporated with section 2

20010621
HFN
Added version transition appendix C

20010621
HFN
Applied new styles to examples

20010621
HFN
Changed term "transport" to "underlying protocol

20010621
HFN
Changed example URNs to URLs of the style http://example.org/...

20010621
MJH
Updated the Acknowledgements section.

20010621
JJM
Added new style sheet definitions (from XML Schema) for examples, and used them for example 1 and 2.

20010621
JJM
Incorporated David Fallside's comments on section Status and Intro sections.

20010620
HFN
Changed the status section

20010620
HFN
Changed title to SOAP Version 1.2 and used that first time in abstract and in body

20010620
HFN
Removed question from section 2.4 as this is an issue and is to be listed in the issues list

20010620
HFN
Moved change log to appendix

20010615
JJM
Renamed default actor to anonymous actor for now (to be consistent)

20010615
JJM
Fixed typos in section 2

20010614
JJM
Updated section 2 to adopt the terminology used elsewhere in the spec.

20010613
MJH
Updated mustUnderstand fault text with additions from Martin Gudgin.

20010613
MJH
Added schema changes appendix from Martin Gudgin.

20010613
MJH
Added mustUnderstand fault text from Glen Daniels.

20010612
MJH
Fixed document <title>.

20010612
MJH
Moved terminology subsection from message exchange model section to introduction section.

20010612
MJH
Fixed capitalisation errors by replacing "... A SOAP ..." with "... a SOAP ..." where appropriate.

20010612
MJH
Removed trailing "/" from encoding namespace URI.

20010612
MJH
Fixed links under namespace URIs to point to W3C space instead of schemas.xmlsoap.org.

20010612
MJH
Removed some odd additional links with text of "/" pointing to the encoding schema following the text of the encoding namespace URI in several places.

20010611
MJH
Incorporated new text for section 2.

20010611
JJM
Changed remaining namespaces, in particular next.

20010609
JJM
Changed the spec name from XMLP/SOAP to SOAP.

20010609
JJM
Changed the version number from 1.1 to 1.2.

20010609
JJM
Changed the namespaces from http://schemas.xmlsoap.org/soap/ to http://www.w3.org/2001/06/soap-.

20010609
JJM
Replaced the remaining XS and XE prefixes to env and enc, respectively.

20010601
MJH
Updated the examples in section 1, 6 and appendix A with text suggested by Martin Gudgin to comply with XML Schema Recommendation.

20010601
JJM
Updated the examples in section 4 and 5 with text suggested by Martin Gudgin, to comply with XML Schema Recommendation.

20010531
HFN
Removed appendices C and D and added links to live issues list and separate schema files.

20010531
MJH
Added this change log and updated schemas in appendix C to comply with XML Schema Recommendation.

D.2 XML Schema Changes

The envelope and encoding schemas have been updated to be compliant with the XML Schema Recomendation[10,11]. The table below shows the categories of change.

Class
Meaning

Addition
New constructs have been added to the schema

Clarification
The meaning of the schema has been changed to more accurately match the specification

Deletion
Constructs have been removed from the schema

Name
The schema has been changed due to a datatype name change in the XML Schema specification

Namespace
A namespace name has been changed

Semantic
The meaning of the schema has been changed

Style
Style changes have been made to the schema

Syntax
The syntax of the schema has been updated due to changes in the XML Schema specification

The table below lists the changes to the envelope schema.

Class
Description

Namespace
Updated to use the http://www.w3.org/2001/XMLSchema namespace

Namespace
Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-envelope

Clarification
Changed element and attribute wildcards in Envelope complex type to namespace="##other"

Clarification
Changed element and attribute wildcards in Header complex type to namespace="##other"

Clarification
Added explicit namespace="##any" to element and attribute wildcards in Body complex type

Clarification
Added explicit namespace="##any" to element and attribute wildcards in detail complex type

Clarification
Added an element wildcard with namespace="##other" to the Fault complex type

Name
Changed item type of encodingStyle from uri-reference to anyURI

Name
Changed type of actor attribute from uri-reference to anyURI

Name
Changed type of faultactor attribute from uri-reference to anyURI

Semantic
Added processContents="lax" to all element and attribute wildcards

Semantic
Chang