- From: David Fallside <fallside@us.ibm.com>
- Date: Mon, 17 Jun 2002 15:25:33 -0700
- To: www-tag@w3.org
Submitted on behalf of the XML Protocol Working Group =========================================================================== The XML Protocol Working Group (XMLP WG) has made changes to Part 2 of the SOAP 1.2 specification, and to the SOAP 1.2 Primer. These changes provide a resolution to what has sometimes been called the "GET issue" [1] that was brought to the XMLP WG's attention by the TAG [2]. The TAG finding to which we are responding states: "RESOLVED.The TAG finds that the absence of a GET binding in SOAP is incompatible with the architecture of the Web, in that it contravenes the architectural principle that important information resources should have URIs. The TAG appreciates the urgency in completing the SOAP 1.2 specifications and wants to work with those concerned to address this problem with the least disruption possible." The XMLP WG's resolution-- which has been accepted by the TAG [3]-- is embodied in SOAP 1.2 documents dated 6 June 2002 and later, especially in Part 2 and the Primer. See the XMLP WG webpage [4] for links to all the SOAP 1.2 documents. For those seeking an overview of our approach, the following is a summary of the changes that we have made. We encourage anyone with a detailed interest in our resolution to read the SOAP 1.2 documents. Summary of changes that have been made to address the TAG's finding: 1. The specification now makes clear that information needed to identify SOAP resources should be in URIs where practical, regardless of whether the operation is GET or POST, or whether SOAP RPC is being used. We have added in the RPC section specific indication that resource identifying information in RPC arguments and method names should be represented in the URI. We provide no further normative commentary about what the URI might look like or how methods and arguments or anything else might be encoded in it. (The Primer does illustrate a few simple examples of ways that method/argument encoding might be done.) 2. We have added explanations of when GET semantics are appropriate for use in retrieving packages of SOAP information, i.e. when the retrievals are safe. Use of GET for safe retrievals is encouraged in both RPC and non-RPC SOAP scenarios, but we have also added detailed discussion of the particular issues that arise when using GET for RPC. 3. We have used the SOAP binding framework to enhance the SOAP HTTP binding to support GET scenarios. Specifically, a new Message Exchange Pattern (MEP) and a new feature are defined, and both are supported by the enhanced HTTP binding. The resulting binding is designed to make appopriate use of HTTP for both POST and GET (e.g. status codes are used correctly, interoperation through proxies should be what one would expect, etc.) The XMLP WG wishes to thank the TAG and the many others involved who helped us to understand the issues and to develop what we believe to be a significant improvement to our design. [1] http://www.w3.org/2001/tag/2002/0505-agenda#L905 [2] http://lists.w3.org/Archives/Public/xmlp-comments/2002May/0018.html [3] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0072 [4] http://www.w3.org/2000/xp/Group/ ...................................... David C. Fallside Chair, XMLP WG Ext Ph: 530.477.7169 fallside@us.ibm.com
Received on Monday, 17 June 2002 19:03:01 UTC