W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2006

New text to go below Table 17 in Request-Optional-Response draft

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 3 May 2006 09:27:26 -0400
To: xml-dist-app@w3.org
Message-ID: <OFC04275FB.39DFA180-ON85257163.0047A2E6-85257163.0049ECC3@lotus.com>
This note is in fulfillment of my action:

        2006/04/26: Noah 
        Draft proposed text after Table 17. 

Note that in the course of drafting this I believe I discovered a related 
set of problems that we need to discuss first:

The New Problem2
---------------

At the time I drafted the original ROR, the design was:

        200 => SOAP envelope
        202 => No SOAP Envelope.

I think we've agreed to change that to:

        200 => SOAP envelope which is the 
             final response
        202 => Optional SOAP envelope with no warranty
             as to how far server is progressed

The problem I noticed is that there are several other places in the draft 
that we have to hit to effect this change.  Notably, 202 is now documented 
as transitioning to "receiving will immedately transition to a "success" 
state, where in fact we model the receipt of an envelope as taking you 
either to sending+receiving or receiving.  So, I think we need to change 
the table 17 definition of 202 to have a NextState of:

        Next State: "Sending+Receiving" or "Receiving".
                  If no SOAP envelope is received, 
                  there will be a subsequent
                  immediate transition to "success"

In the same row, the significance/action description for 202 now says:

<current>
"The request has been accepted, but no response envelope is provided. Any 
further application processing is beyond the scope of this use of the 6.2 
SOAP Request-Response Message Exchange Pattern***."
</current>

I think that needs to be something like:

<proposed>
"The request has been accepted, but the server makes no commitment as to 
whether processing of the request has been completed.  If a response SOAP 
envelope is provided, than it may represent a partial response or a status 
update on progress of requst processing; if no response envelope is 
provided, then any further application processing is beyond the scope of 
this use of the 6.2 SOAP Request-Response Message Exchange Pattern***."
</proposed>

Proposed Text Below Table 17
----------------------------

With the above in hand, I think we want to put the new text mandated by my 
action not below table 17, which is the documentation of the requesting 
state, but in the discussion of 7.5.1.5 "Success and fail" 

The full status quo text of that section is currently:

<current>
7.5.1.5 Success and Fail

"Success" and "Fail" are the terminal states of the Request-Response and 
SOAP-Response MEPs. Control over the message exchange context returns to 
the local SOAP node.
</current>

I propose to add what we had planned for below table 17 to the end of 
7.5.1.5, yielding:

<proposed>
7.5.1.5 Success and Fail

"Success" and "Fail" are the terminal states of the Request-Response and 
SOAP-Response MEPs. Control over the message exchange context returns to 
the local SOAP node. 

If the "success" state has been reached and if a SOAP envelope has been 
received, then the local node is a SOAP Receiver as defined in (reference 
to section 1.5.3 of SOAP Part 1] [1]), and in particular MUST obey the 
requirement of [reference to SOAP Part 1 Section 2.1 "SOAP Nodes"] [2] to 
process the message according to the SOAP Processing Model [reference to 
Part 1 section 2.6] [3].
</proposed>

I believe this fulfills my assigned action.  I do expect to be on the call 
today, and we can discuss this proposal at that time


[1] http://www.w3.org/TR/soap12-part1/#senderreceiverconcepts
[2] http://www.w3.org/TR/soap12-part1/#soapnodes
[3] http://www.w3.org/TR/soap12-part1/#procsoapmsgs

</proposed>


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Wednesday, 3 May 2006 13:27:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:21 GMT