W3C home > Mailing lists > Public > www-tag@w3.org > June 2002

Summary of resolution to TAG Get finding

From: David Fallside <fallside@us.ibm.com>
Date: Mon, 17 Jun 2002 15:25:33 -0700
To: www-tag@w3.org
Message-ID: <OF142E12C2.A48E4B6F-ON88256BDB.00782B05@boulder.ibm.com>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:32 UTC