Re: FW: Last Call comments on SOAP 1.2 from the XForms WG

Micah Dubinko writes:

>> b) [Part0 3.1.1. SOAP HTTP GET usage]
>> Please mention that to use an XML SOAP 
>> envelope as XForms external instance
>> data, HTTP GET usage (SOAP Response 
>> Message Exchange Pattern) is required.
>> At the editors' discretion, you might 
>> also mention other similar cases, such
>> as document() in XSLT, etc.

Speaking for myself as opposed to the XMLP WG, I agree with the spirit of 
this, but not the exact proposal.  The subtlety is this:  when you 
formally refer to a SOAP MEP, you are mandating not just the pattern of 
bits on the wire, but also the requirement to do SOAP processing of the 
received envelopes.   Indeed, one reason for creating the Response-Only 
MEP as opposed to just saying "you can do a GET and a SOAP envelope will 
come back" is to give a formal statement that SOAP processing is done on 
the received SOAP responses, that mU faults are to be detected, etc. 
If this is ineed what XForms needs (which I doubt), then the reference to 
the SOAP Response MEP would indeed be appropriate as suggested.  If, 
however, we just want to get back a SOAP envelope as XML to be processed 
by non-SOAP means (parsed with XSLT, some XForms mechanism or whatever), 
then that is NOT the normative use of the Response MEP.  In this case, 
we're in the realm of the note at the end of Part 2 section 7.1 which says 
[1]:

"Note:

Particularly when used with the 6.3 SOAP Response Message Exchange 
Pattern, the HTTP messages produced by this binding are likely to be 
indistinguishable from those produced by non-SOAP implementations 
performingsimilar operations. Accordingly, some degree of interoperation 
can be made possible between SOAP nodes and other HTTP implementations 
when using this binding. For example, a conventional Web server (i.e. one 
not written specifically to conform to this specification) might be used 
to respond to SOAP-initiated HTTP GET's with representations of 
content-type "application/soap+xml". Such interoperation is not a 
normative feature of this specification."

We could, if those involved feel it's appropriate, include a specific 
reference to XForms, XSLT, etc.   Note that whenever SOAP processing is 
not done, you lose the power of SOAP's compatibility (I.e. mustUnderstand) 
targeting (role=) and other similar mechanisms.  Indeed, that's among the 
reasons that such operation is permitted but non-normative.  The robust 
model for processing a SOAP message is using the SOAP processing model. 

I hope this explanation is helpful.  Thank you very much.

[1] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#http-intro

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

Received on Thursday, 8 August 2002 23:27:00 UTC