W3C home > Mailing lists > Public > xmlp-comments@w3.org > June 2003

Resolution for PR issue 430

From: Nilo Mitra (EUS) <Nilo.Mitra@am1.ericsson.se>
Date: Tue, 3 Jun 2003 16:53:23 -0500
Message-ID: <77BEF8ACD6CB1B4DA605D9D9CF554AEB126ACC@eamrcnt727.exu.ericsson.se>
To: "'zvi.b@sapiens.com'" <zvi.b@sapiens.com>
Cc: "'xmlp-comments@w3.org'" <xmlp-comments@w3.org>

Hello Zvi:
You raised an issue[1], which we have classified as PR issue#430 [2], which 
is a text/example disagreement involving examples 9 and 13 in the SOAP 
Primer [3]. Thank you for noting this discrepancy. The WG has resolved this
with the following amendments to the Primer.

1. In example 9, replace the first line with:
POST /Reservations HTTP/1.1

2. Rewrite the 1st para following example 9 (>>deletions<<, <<additions>>) thus:

"Example 9 shows an RPC request directed at >>a specific reservation at<< the travel 
service application. The SOAP message is sent in the body of a HTTP POST method 
directed at the URI identifying the >>specific reservation<< <<"Reservations" resource
on the server travelcompany.example.org>>. When using HTTP, the request URI indicates 
the resource to which the invocation is "posted". Other than <<requiring that>> it be a 
valid URI, SOAP places no formal restriction on the form of the request URI (see [RFC 2396] 
for more information on URIs). However, one of the principles of the Web architecture is 
that all important resources be identified by URIs. This implies that most well-architected 
SOAP services will be embodied as a large number of resources, each with its own URI. Indeed, 
many such resources are likely to be created dynamically during the operation of a service, 
such as, for instance, the specific travel reservation shown in the example. So, a 
well-architected travel service application >>will<< <<should>> have different 
URIs for each reservation, and SOAP requests to retrieve or manipulate those reservations 
will be directed at their URIs, and not at a single monolithic "reservations" URI, <<as
shown in Example 9>>.<< Example 13 in section 4.1.3 shows the preferred way to address
resources such as a particular travel reservation. Therefore, we defer until section 4.1.3 
further discussion of Web architecture compatible SOAP/HTTP usage.>>"

3. Delete the 2nd para following Example 9 (it will be moved and merged into section 4.1.3, 
see item 5 below).

4. Rewrite the 1st para **before** Example 13 (>>deletions<<, <<additions>>) thus:

"Example 13 is the same as that in Example 9, except that the <<HTTP>> Request-URI has been 
modified to include the reservation code, which serves to identify the resource (the reservation 
in question, which is being confirmed and paid for) >>, while the other parameters in the RPC, 
such as the creditCard number are ancillary data to be processed by the resource. Note, however, 
that all the resource-identifying elements have been retained as in Example 9 in their encoded 
form in the SOAP env:Body element<< . 

5. Add a **new** paragraph just **after** Example 13 with the following text (modified deleted text 
from item 3 above):

"In Example 13, the resource to be manipulated is identified by two things: the first is that it 
is a reservation (part of the method name), and the second is the specific instance of a reservation 
(which is the value of the parameter code to the method). The remainder of the parameters in the RPC 
such as the creditCard number are not resource-identifying, but are ancillary data to be processed 
by the resource. It is the recommendation of [SOAP Part2] that resources that may be accessed by 
SOAP-based RPCs should, where practical, place any such resource-identifying information as a part 
of the URI identifying the target of the RPC. It should be noted, however, that [SOAP Part2] does 
not offer any algorithm to do so. Such algorithms may be developed in future. Note, however, that 
all the resource-identifying elements have been retained as in Example 9 in their encoded form in 
the SOAP env:Body element."

These changes can be seen in the latest editor's copy of the Primer, available at [4].

Please let the WG know via xmlp-comments@w3.org if you are not satisfied with this proposal.

Thank you,
Nilo Mitra
editor, SOAP Primer
on behalf of the XMLP WG

[1] http://lists.w3.org/Archives/Public/xmlp-comments/2003May/0009.html
[2] http://www.w3.org/2000/xp/Group/xmlp-pr-issues.html#x430
[3] http://www.w3.org/TR/2003/PR-soap12-part0-20030507/
[4] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part0.html

Nilo Mitra
Ericsson, Inc.
phone: + 1 212 843 8451
mobile: +1 516 476 7427
Received on Tuesday, 3 June 2003 17:53:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:59 UTC