Comments inline
________________________________
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]
On Behalf Of Christopher B Ferris
Sent: Wednesday, January 11, 2006 8:11 PM
To: xml-dist-app@w3.org
Subject: Re: Preliminary work on making envelope optional
Noah/All,
Nice job. Some comments on the revised HTTP binding.
6.2.2 Description
***The SOAP Request-Response MEP defines a pattern for the exchange of a
SOAP message acting as a request followed by a message acting as a
response. The response message MAY contain a SOAP envelope, or else the
response MUST be a binding-specific message indicating that the request
has been received. In the absence of failure in the underlying protocol,
this MEP consists of exactly two messages.
I think that it may make more sense to state the following:
The response message is a binding-specific response that MAY
contain a SOAP envelope.
I would not make any claims as to what the response message indicates
(e.g. whether or not the message was received).
>DBO> I said "The SOAP Request-Response MEP defines a pattern for the
exchange of a message acting as a request optionally followed by a
message acting as a response. The messages may or may not carry SOAP
envelopes. In the absence of failure in the underlying protocol, this
MEP consists of one request message and one optional response message:"
In the normal operation of a message exchange conforming to the
Request-Response MEP, a request message is first transferred from the
requesting SOAP node to the responding SOAP node. Following the
successful processing of the request message by the responding SOAP
node, a response message is transferred from the responding SOAP node to
the requesting SOAP node.
How about:
In the normal operation of a message exchange conforming to the
SOAP Request-Response MEP, a request message, containing a SOAP
envelope, is ...
>DBO> I said "In the normal operation of a message exchange conforming
to the Request-Response MEP, a request message is first transferred from
the requesting node to the responding node. Following the successful
processing of the request message by the responding node, a response
message may be transferred from the responding node to the requesting
node.
In Table 7 in the Transition column on the "Receiving" row it reads:
***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.
I'm a little confused. The definition of the OutboundMessage is:
An abstract structure that represents the current outbound
message in the message exchange. This abstracts both SOAP Envelope and
any other information structures that are transferred along with
the envelope.
It seems to me that in the case of an HTTP 202 Accepted response, that
something needs to tell the binding that the message was accepted. I
would have thought that that would constitute "other information
structures", but maybe not? Does this mean that there's a missing
property? Something that indicates to the binding layer the disposition
of the received message? Just a thought.
>DBO> I would think that setting a "null" for the response envelope in
the OutboundMessage does this. I have purposefully underspecified this.
Similarly, in the Action column corresponding to the above it says:
***Initiate transmission of response message. If an envelope is
provided in abstracted in
http://www.w3.org/2003/05/soap/mep/OutboundMessage then include
that in the response message.
The part that says: "if an envelope is provided in abstracted..." seems
to imply that the envelope is optional in the OutboundMessage (in the
context of the responding SOAP node), which seems to suggest as I did
above, that the disposition is actually a part of the abstraction of
OutboundMessage. I think that it will be important that we make this
clear and consistent. I personally think that in all cases, there is an
OutboundMessage. It may, or may not as the case may be, contain a SOAP
envelope. Thus, I think that we could leave the transition column above
as:
Start of response envelope available in
http://www.w3.org/2003/05/soap/mep/OutboundMessage
>DBO> I prefer Noah's formulation. I don't think that a null envelope
is a response envelope. It's a response that is in the OutboundMessage
but it's not an envelope.
Table 19
***Only if status line is 200, the SOAP message serialized
according to the rules for carrying SOAP messages in the media type
given by the Content-Type header field.
Actually, a SOAP fault should be accompanied by one of the HTTP response
codes as defined in table 20. I think it would be best to say:
Unless the status line is 202, the SOAP message ...
>DBO> I said "The response message, if any, may contain a SOAP envelope.
If so, it will be serialized according to the rules for carrying SOAP
messages in the media type given in the Content-Type header field."
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
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 01/10/2006 07:40:32 PM:
>
> 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
> --------------------------------------
>
>
>
>
>