Re: Preliminary work on making envelope optional

Very nice work, Noah.  I think it's important to keep the changes to
an absolute minimum to minimize the potential impact on deployed code.
 A couple of editorial nits;

In table 7, current state = "receiving", the 2nd transition condition,
s/send/sent.

In the corresponding action in table 7, this sentence seems in error
"If an envelope is provided in abstracted in
http://www.w3.org/2003/05/soap/mep/OutboundMessage [...]".

My only substantive response is that in table 17, I think it's
perfectly fine if a SOAP response is returned on a 202 response. 
What's most important to indicate, I believe, is that because of the
semantics of 202, that any SOAP envelope would not represent the
results of processing the inbound SOAP message.  It only indicates an
intermediate result, like an ack.  So I'd suggest this text instead;

"The request has been accepted, and any information that might be
present in the response message, possibly including a SOAP envelope,
does not represent the results of processing the request message. Any
further application processing is beyond the scope of this use of the
6.2 SOAP Request-Response Message Exchange Pattern***."

Of course, that change does prompt the question ... why do we need to
make the other changes to support a response with an optional SOAP
envelope? 8-O

Mark.

On 1/10/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote:
>
> Following up on my message of yesterday [1], I have updated the draft to
> include a first cut at a revised HTTP binding [2,3].  I fixed one or two
> other misstatements in yesterday's draft as well, so you should reread the
> whole thing.  As expected, the changes are relatively straightforward, and
> are mostly aimed at specifying the use of status code 202.  As with the
> first posting, you can find all of the changed text by searching for
> "***", which I used as a preliminary form of diff markup.  I'm sorry I
> didn't get this done earlier, but perhaps we can have a preliminary
> discussion on the call tomorrow.  I added a couple of ednotes as well.
>
> Also, I seem for the moment to have lost control of the date line on the
> title page.  It erroneously lists the revision date as tomorrow: "editors'
> copy $Date: 2006/01/11 00:29:32 $".  I have no idea where the stylesheet
> is getting this, as I've checked both the xml source and the dtd.  Surely
> I'm missing something obvious.  Since this is just a branch draft for
> discussion, I won't worry about it for now.  If we decide to integrate
> these changes as an official editor's copy then we'll have to fix it.
>
> Again, I must apologize for not having also read and reviewed David
> Orchard's draft.  Now that I've completed my action item, I can get back
> to that.  I do think the direction signaled in [2] is workable, is a
> modest change to our already published rec, and is generally promising.
> Obviously I won't comment on the comparison with David's approach until
> I've had a chance to read and think about it.
>
> Enjoy.
>
> Noah
>
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0037.html
> [2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html
> [3] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.xml
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>


--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Received on Wednesday, 11 January 2006 18:29:28 UTC