Re: status of ROR

Thanks, Noah

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

Noah Mendelsohn/Cambridge/IBM wrote on 08/23/2006 01:24:20 AM:

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