While Web services will migrate toward SOAP 1.2 in the near future, the most prevalent Web services technology today is the now deprecated SOAP 1.1. Although there isn't a great deal that has changed between the two revisions, there are some caveats we must be aware of when dealing with SOAP 1.1-based systems. To ensure that the work we've invested in understanding SOAP 1.2 isn't lost on SOAP 1.1 systems, we shall finish our coverage of SOAP with a set of notes that should make our SOAP 1.2 knowledge backwardly compatible with SOAP 1.1.
 These notes are abridged from the SOAP 1.2. Primer document which can be found at: http://www.w3.org/TR/2002/WD-soap12-part0-20020626/
Syntactic Differences between SOAP 1.2 and SOAP 1.1
SOAP 1.2 does not permit any element after the body. The SOAP 1.1 schema definition allowed for such a possibility, but the textual description is silent about it. However, the Web Services Interoperability Organization (WS-I) has recently disallowed this practice in its basic profile and as such we should now consider that no elements are allowed after the SOAP body, since any other interpretation will hamper interoperability.
SOAP 1.2 does not allow the encodingStyle attribute to appear on the SOAP Envelope, while SOAP 1.1 allows it to appear on any element.
SOAP 1.2 defines the new Misunderstood header element for conveying information on a mandatory header block that could not be processed, as indicated by the presence of a mustUnderstand fault code. SOAP 1.1 provided the fault code, but no details on its use.
In the SOAP 1.2 infoset-based description, the mustUnderstand attribute in header elements takes the (logical) value true or false while in SOAP 1.1 they are the literal value 1 or 0, respectively.
SOAP 1.2 provides a new fault code DataEncodingUnknown.
The various namespaces defined by the two protocols are different.
SOAP 1.2 replaces the attribute actor with role but with essentially the same semantics.
SOAP 1.2 defines two new roles, none and ultimateReceiver, together with a more detailed processing model on how these behave.
SOAP 1.2 has removed the dot notation for fault codes, which are now simply of the form env:name, where env is the SOAP envelope namespace.
SOAP 1.2 replaces client and server fault codes with Sender and Receiver.
SOAP 1.2 uses the element names Code and Reason, respectively, for what is called faultcode and faultstring in SOAP 1.1.
SOAP 1.2 provides a hierarchical structure for the mandatory SOAP Code element, and introduces two new optional subelements, Node and Role.
Changes to SOAP-RPC
Though there was some feeling in the SOAP community that SOAP RPC has had its day and should be dropped in favor of a purely document-oriented protocol, the widespread acceptance of SOAP RPC has meant that it persists in SOAP 1.2, but with a few notable differences:
SOAP 1.2 provides a rpc:result element accessor for RPCs.
SOAP 1.2 provides several additional fault codes in the RPC namespace.
SOAP 1.2 allows RPC requests and responses to be modeled as both structs as well as arrays. SOAP 1.1 allowed only the former construct.
SOAP 1.2 offers guidance on a Web-friendly approach to defining RPCs where the method's purpose is purely a "safe" informational retrieval.
Given the fact that SOAP RPC is still supported in SOAP 1.2 and that there have been some changes to the RPC mechanism, some portions of the SOAP encoding part of the specification have been updated to either better reflect the changes made to SOAP RPC in SOAP 1.2, or to provide performance enhancements compared to their SOAP 1.1 equivalents.
An abstract data model based on a directed edge-labeled graph has been formulated for SOAP 1.2. The SOAP 1.2 encodings are dependent on this data model. The SOAP RPC conventions are dependent on this data model, but have no dependencies on the SOAP encoding. Support of the SOAP 1.2 encodings and SOAP 1.2 RPC conventions are optional.
The syntax for the serialization of an array has been changed in SOAP 1.2 from that in SOAP 1.1.
The support provided in SOAP 1.1 for partially transmitted and sparse arrays is not available in SOAP 1.2.
SOAP 1.2 allows the inline serialization of multi-ref values.
The href attribute in SOAP 1.1 of type anyURI, is called ref in SOAP 1.2 and is of type IDREF.
In SOAP 1.2, omitted accessors of compound types are made equal to NILs.
SOAP 1.2 provides several fault subcodes for indicating encoding errors.
Types on nodes are made optional in SOAP 1.2.
While most of these issues are aimed at the developers of SOAP infrastucture, it is often useful to bear these features in mind for debugging purposes, especially while we are in the changeover period before SOAP 1.2 becomes the dominant SOAP version.