- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 5 Feb 2003 17:26:58 -0500
- To: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
- Cc: xml-dist-app@w3.org
Jeffrey Schlimmer asks: >> What is the processing model for this definition of "message"? I don't have time to dig up all the references, but I think the SOAP recommendation is reasonably clear. A node receiving the message must reconstruct the Envelope infoset and do the processing described in Part 1 chapter 2, >> as augmented by any features <<. I suspect that the crux of your question is: what about all that other stuff like attachments? Should it be relayed by intermediaries, signed, etc? As far as the SOAP spec is concerned, all that stuff is extension features. In the case of attachments, there should be features describing their processing, and relating it if necessary to the SOAP processing model. The whole point is that SOAP includes very little in the core, so if you define extensions that go beyond what the SOAP processing model covers, you should expect to have to write a specification that says what to do. This is not new, IMO. Consider the WebMethod feature. It indicates that there is information (I.e. GET/POST indication) that is carried outside of the envelope. Where do we specify what to do with that? The feature indicates, at least informally, that these verbs describe the operation to be performed by a receiving node. Like many features, it relies on a protocol binding to give a concrete implementation of those semantics. In the case of WebMethod, the HTTP binding does this by specifying the on-the-wire representation (as the HTTP method) and the processing semantics. As far as I can tell SOAP works fine, and is staying quite true to its model of providing a relatively minimal but extensible framework in the core. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Wednesday, 5 February 2003 17:29:44 UTC