Re: status of ROR

I have prepared and checked into CVS a new editors' draft at [1,2]. Please 
accept my regrets for tomorrow's telcon, as I will be flying back from the 
schemas meeting.

The following describe the changes since the previous editors draft, using 
Chris' instructions as a guide.

> Starting with the draft used to produce this editor's version: 
>         
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html 

Done.  I merged the soap12-part2OptRespMEP.xml into soap12-part2.xml. 
Diffs suggest that I did the merge faithfully and did not unintentionally 
back out other changes (actually, I didn't find any conflicts), but it 
would be good if anyone who knows of changes made since 2005/12/21 would 
doublecheck that they have survived intact.

> Change Table 7 - "Receiving" row
> 
> From: 
> '***Either a) Start of response envelope available in 
> http://www.w3.org/2003/05/soap/mep/OutboundMessage or b) indication 
> from the application that no such envelope is to be send in the
> response.'
> 
> To: 
> 'Start of response available in
> http://www.w3.org/2003/05/soap/mep/OutboundMessage.' 

Done.


> Change Table 17, row 2 column 3 from: 
> 
>         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***. 
> 
> to: 
> 
>         The request has been accepted, but either (a) no response 
envelope 
>        is provided or (b) an envelope representing information related 
to 
>        the request is provided -- such envelopes SHOULD be processed 
using 
>        2.6 SOAP Processing model. 

Done.

 > (note that the reference to sect 2.6 should probably be a hyperlink 
> to the relevant section in SOAP1.2 part 1)

In keeping with the style of similar references, the exact text is now:

The request has been accepted, but either (a) no response envelope is 
provided or (b) an envelope representing information related to the 
request is provided -- such envelopes SHOULD be processed using the SOAP 
Processing model (see SOAP 1.2 Part 1 >>>[SOAP Part 1]<<<, section >>>SOAP 
Processing Model<<<).

The >>>XXX<<< are added in this email to show where hyperlinks are. 
>>>[SOAP Part 1]<<< is our traditional reference to the biblio entry for 
SOAP Part 1, and >>>SOAP Processing Model<<< is a direct link to 2.6 in 
part 1.  Essentially the same construction is used elsewhere in Part 2, 
though it should be noted that there are also several places where part 2 
asks you to use the SOAP processing model without hyperlinking it.   I 
think what I've checked in is one of the several acceptable forms, but I 
suppose we could entertain motions to make them all consistent.   I 
believe they've been inconsistent in style all along.

> Finaly,  Replace: 
> <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>
> 
> with: 
> 
> <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> 

Done, modulo similar editorial license on the form of hyperlinks to part 
1.

So, I think we're all set with the merge that Chris had requested, and I 
believe that I have fulfilled my editorial responsibility to the group on 
this, at least for now.

Noah

[1] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.xml
[2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Christopher B Ferris <chrisfer@us.ibm.com>
Sent by: xml-dist-app-request@w3.org
08/07/2006 08:40 AM
 
        To:     Christopher B Ferris <chrisfer@us.ibm.com>
        cc:     xml-dist-app@w3.org, xml-dist-app-request@w3.org, (bcc: 
Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: status of ROR



Fulfilling my AI, here is, what I believe to be the set of edits needed to 
be applied to fully resolve 
SC1, 2 and 3. 

Starting with the draft used to produce this editor's version: 
        
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html 

Change Table 7 - "Receiving" row

From: 
'***Either a) Start of response envelope available in 
http://www.w3.org/2003/05/soap/mep/OutboundMessage or b) indication 
from the application that no such envelope is to be send in the
response.'

To: 
'Start of response available in
http://www.w3.org/2003/05/soap/mep/OutboundMessage.' 


Change Table 17, row 2 column 3 from: 

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

to: 

        The request has been accepted, but either (a) no response envelope 

       is provided or (b) an envelope representing information related to 
       the request is provided -- such envelopes SHOULD be processed using 

       2.6 SOAP Processing model. 

(note that the reference to sect 2.6 should probably be a hyperlink to the 
relevant section in SOAP1.2 part 1) 

Finaly,  Replace: 
<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>

with: 

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

Cheers, 

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295 

xml-dist-app-request@w3.org wrote on 08/01/2006 08:43:23 AM:

> 
> Fulfilling my AI regarding the historical record of where we were 
> with regards to the ROR, I find that we 
> had resolved all three issues (SC1, 2 and 3) and had slightly 
> amended the proposed text, and that 
> what remained was to do a thorough review (which does not appear to 
> have been done). 
> 
> What isn't clear is whether there is a draft of the spec that 
> reflects all of these changes. I suspect 
> that there is not, and that we will need to start with Noah's draft 
> and apply the edits from the 
> resolutions to SC1, 2 and 3 and all of the other resolutions as 
> outlined below. Once that has been 
> produced, I think that we all need to do a thorough review and 
> report any other necessary tweaks to 
> make consistent. 
> 
> The following is the relevant bits collected from the minutes as 
> well as from emails related to 
> closing SC1, 2 and 3 from the end of April and beginning of May. 
> 
> Minutes of April 26 telcon seem to reflect that we had resolved SC1,
> 2, and 3 with proposed 
> amendment from me (expressed in the minutes) and that Mike was to 
> draft text for the 
> modified text for the spec (not done). >From the minutes: 
>         http://lists.w3.org/Archives/Member/w3c-xml-protocol-
> wg/2006Apr/att-0014/2006-04-26-minutes.html 
> 
> [NEW] ACTION: Mike to Draft text for "before dashes" based on 
> Chris's friendly amendment. [recorded in http://www.w3.
> org/2006/04/26-xmlprotocol-minutes.html#action02] 
>         (DONE) http://lists.w3.org/Archives/Public/xml-dist-
> app/2006May/0000.html
> [NEW] ACTION: Mike to Show the conclusions of SC3 to the mailing 
> list. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.
> html#action03] 
>         (DONE) http://lists.w3.org/Archives/Public/xml-dist-
> app/2006May/0001.html
> [NEW] ACTION: Noah to Draft proposed text after Table 17. [recorded in 
> http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action01] 
>         (DONE) http://lists.w3.org/Archives/Public/xml-dist-
> app/2006May/0003.html 
> 
> From the minutes of May 3, 2006: 
>         http://lists.w3.org/Archives/Member/w3c-xml-protocol-
> wg/2006May/0003.html 
> 
> > 5. SOAP 1.2 PER 
> > 
> > Proposal for ROR
> >   Reworked proposal:
> > http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
> >   HTML Part2 proposal:
> > http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html
> > 
> > Issues:
> > 
> >   SC1: 202 semantics. Table 17 for status code 202 row.
> >   http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0052.html
> >   - I believe this is now moot, see (NM/MB exchange):
> >   http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0008.html
> >   - Yet now continuing 202 and RX (2 separate requests) thread (DH):
> >   http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0009.html
> >   - New proposed text from last week around Table 17. Mike will post 
> >   agreed material, Noah will post new clarifying text after Table 17.
> >   PENDING
> 
> Noah: Based on last week's discussion, we agreed that an HTTP 202
> response could indicate an optional SOAP envelope will follow.  Found
> that there is text around the table that relies on the fact that there
> is no response envelope.  Proposed text:
> 
>  "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***."
> 
> Mike: We already accepted text from Chris for this part of the table.
> 
> Noah: Use Chris' text, unless the above is better.
> Next, text states that there will be immediate transition from
> "receiving" to "success" as soon as 202 is received.  Should be from
> both "sending+receiving" and "receiving", if no envelope is received.
> 
> DavidH: Comfortable with Noah's proposed text.
> 
> Noah: Table 17 is in a section entitled "Requesting".  But this
> transition is to "success", so also needed to draft text for 7.5.1.5
> "Success and Fail".
> 
> Mike: Does this add conformance criteria?
> 
> Noah: No, it's just clarification.
> 
> DavidH: This won't change existing "200" implementations, because they
> do this anyway.
> 
> Noah: New proposed text:
> If the "success" state has been reached, either as a result of ... or 
...
> [See IRC log at http://www.w3.org/2006/05/03-xmlprotocol-irc
> Access to log is forbidden at the time minutes are being submitted.]
> 
> Noah: Bug in 7.5.1.4:
> Indicate status code 200 ... response includes soap envelope....
> Need to remove this.
> Look for everywhere the spec implies that 202 has no envelope.
> 
> ACTION: Yves to perform critical review of changes SC1, SC2, SC3 to
> ensure the result is complete.
> 
> >   SC2: Semantics of response message. 6.2.2
> >   http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0051.html
> >   - reworked in last telecon. New text is at:
> >   http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0023.html
> >   If no more pushback, then this is the final text
> >   DONE
> > 
> >   SC3: OutboundMessage abstraction
> >   http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0050.html
> >   - discussed at some length last week, search for SC3
> > 
> > 
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Apr/att-0004
> >    /2006-04-05-minutes.html
> >   - Chris has a action here
> >   DONE - final text from Chris. Mike will repost to list. 
> 
> Noah in his response to the posted draft minutes wrote: 
>         http://lists.w3.org/Archives/Member/w3c-xml-protocol-
> wg/2006May/0004.html 
> 
> As minuted:
> 
> > Next, text states that there will be immediate transition from
> > "receiving" to "success" as soon as 202 is received.  Should be from
> > both "sending+receiving" and "receiving", if no envelope is received.
> 
> I think that should be:
> 
> Next, text states that there will be immediate transition from 
"receiving" 
> to "success" as soon as 202 is received.  Should be >to< either 
> "sending+receiving" and "receiving", and then immediately to "success" 
if 
> no envelope is received.
> 
> Do I have that right? 
> 
> 
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295

Received on Wednesday, 23 August 2006 05:24:40 UTC