From ssax-sxml-admin@lists.sourceforge.net Mon May 26 19:55:35 2003 Message-ID: <200305261953.h4QJrOd2041628@adric.fnmoc.navy.mil> To: ssax-sxml@lists.sourceforge.net Reply-To: oleg-at-pobox.com From: oleg-at-pobox.com Subject: [ssax-sxml] SOAP 1.2 List-Archive: X-Original-Date: Mon, 26 May 2003 12:53:24 -0700 (PDT) Date: Mon, 26 May 2003 12:53:24 -0700 (PDT) Status: OR Hello! Two weeks ago SOAP 1.2 (what used to be known as XML protocol) became a W3C Proposed Recommendation. SOAP 1.2 is quite different from SOAP 1.1 and XML-RPC. In particular, the name "SOAP" is no longer an abbreviation (probably because it is not simple and in no way is particular to objects). The most interesting part of SOAP 1.2 is the one that permits SXML (s-expression) message systems to claim SOAP 1.2 compliance. Indeed, SOAP does *not* require XML! The normative part of the Recommendation is Part 1, Messaging framework: http://www.w3.org/TR/soap12-part1/ Part 2, adjuncts, is a guide, by way of examples, for defining custom features, message exchange patterns, and protocol bindings: http://www.w3.org/TR/soap12-part2/ Section 1.3 of the normative SOAP Version 1.2 Part 1 says:
A SOAP message is specified as an XML Information Set [XML InfoSet]. While all SOAP message examples in this document are shown using XML 1.0 [XML 1.0] syntax, other representations MAY be used to transmit SOAP messages between nodes (see 4. SOAP Protocol Binding Framework). ... 4.2 Binding Framework As described in 5. SOAP Message Construct, each SOAP message is specified as an XML infoset that consists of a document information item with exactly one child: the SOAP Envelope element information item. Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP message infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol. The binding framework does not require that every binding use the XML 1.0 [XML 1.0] serialization as the "on the wire" representation of the XML infoset; compressed, encrypted, fragmented representations and so on can be used if appropriate. A binding, if using XML 1.0 serialization of the XML infoset, MAY mandate that a particular character encoding or set of encodings be used."
In other words, the W3 Consortium specifically leaves it to applications to choose the appropriate on-the-wire representation of the XML Infoset. S-expressions is one of the realizations of the XML Infoset. Thus serializing SOAP messages using SXML is specifically permitted. Indeed, S-expressions may reasonably be characterized as a "compressed representation" of the XML Infoset. SOAP 1.2 conformance requirements are not strict:
For an implementation to claim conformance with the SOAP Version 1.2 specification, it MUST correctly implement all mandatory ("MUST") requirements expressed in Part 1 of the SOAP Version 1.2 specification (this document) that pertain to the activity being performed. Note that an implementation is not mandated to implement all [sic!] the mandatory requirements . For example, a special purpose implementation that never sends a SOAP header block can claim conformance provided that it correctly implements the mandatory requirements that pertain to the messages it does send.
Furthermore, the processing of SOAP request bodies is entirely to an application:
2.5 Structure and Interpretation of SOAP Bodies An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, with the exception of SOAP faults (see 5.4 SOAP Fault), Part 1 of this specification (this document) mandates no particular structure or interpretation of these elements, and provides no standard means for specifying the processing to be done.
We should note that particular SOAP headers and particular children of the SOAP Body element may use their own encoding (serialization), provided that they specify an appropriate encodingStyle Attribute. For example, the following message (modeled after Example 1 in the SOAP Recommendation, Part 1) conforms to SOAP 1.2: (priority 1) (expires (from "2001-06-22T14:00") (to "2001-06-22T14:05")) (msg "Pick up Mary at school at 2pm") SOAP Version 1.2 Part 2, describes, among other things, a binding of SOAP 1.2 to HTTP. The document specifically says "The SOAP HTTP Binding is optional and SOAP nodes are NOT required to implement it. The SOAP version 1.2 specification does not preclude development of other bindings to HTTP or bindings to other protocols." Still, even the described binding says:
7.1.4 HTTP Media-Type Conforming implementations of this binding: 1. MUST be capable of sending and receiving messages serialized using media type "application/soap+xml" whose proper use and parameters are described in A. The application/soap+xml Media Type. 2. MAY send requests and responses using other media types providing that such media types provide for at least the transfer of SOAP XML Infoset. 3. MAY, when sending requests, provide an HTTP Accept header field. This header field: - SHOULD indicate an ability to accept at minimum "application/soap+xml". - MAY additionally indicate willingness to accept other media types that satisfy 2 above.
That is, even the sample HTTP binding explicitly permits other ways of serializing XML infosets. We may use, e.g., a MIME type text/x-sxml. A compliant server implementation of the binding may accept SOAP messages in XML and SXML. If the client has not indicated its willingness to accept text/x-sxml, the server will simply send a SOAP Fault XML message. That scenario fully conforms to SOAP 1.2 and SOAP 1.2 HTTP binding.