- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Wed, 23 Aug 2006 07:02:03 -0400
- To: xml-dist-app@w3.org
- Message-ID: <OF50B8C8CA.9823C0D8-ON852571D3.00070DF6-852571D3.003C9AE4@us.ibm.com>
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
----- Forwarded by Christopher B Ferris/Waltham/IBM on 08/22/2006 09:17 PM
-----
Noah Mendelsohn <noah_mendelsohn@yahoo.com>
08/22/2006 05:57 PM
To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
Subject
New Drafts of SOAP 1.2 Part 2 Posted
Chris: I'm stuck behind a Microsoft firewall that is
keeping me from sending IBM mail. Thought you would
want to know about attached ASAP. The formal note
should go out tonight when I dial up from the hotel.
Feel free to pass this on to distApp, but
PLEASE MAKE SURE MY YAHOO MAIL ADDRESS DOES NOT APPEAR
IN THE W3C ARCHIVES OR IT WILL BE SPAMMED MERCILESSLY.
Thanks.
Noah
From: Noah Mendelsohn
To: Christopher B Ferris <chrisfer@us.ibm.com>
cc: xml-dist-app@w3.org
Subject: 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
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Received on Wednesday, 23 August 2006 11:02:30 UTC