XML, SOAP and Binary Data(3)

The disadvantages of having two data models are especially problematic for SOAP itself. The SOAP specifications were designed around the notion that a SOAP message is simply an XML-based SOAP:Envelope. In SOAP/1.1, the definition of a SOAP message is fairly simple:

The SOAP Envelope element is the top element of the XML document representing the SOAP message.

Throughout the SOAP/1.1 specification, SOAP messages are routinely referred to as the SOAP Envelope. This excerpt from Section 1.3 is one example of this:

[The] following is the response message containing the HTTP message with the SOAP message as the payload:

Following the precedent set forth by SOAP/1.1, the July 2001 SOAP/1.2 Working Draft [soap12wd] (the first public WD from the XMLP WG) states the following:

A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP Header, and a mandatory SOAP Body. This XML document is referred to as a SOAP message for the rest of this specification.

This definition has been consistent for the two-year history of the XMLP WG's drafts of the SOAP 1.2 specification. Here is the prose from the December 2002 Candidate Recommendation of SOAP/1.2 [soap12cr]:

A SOAP message is specified as an XML Infoset that consists of a document information item with exactly one member in its [children] property, which MUST be the SOAP Envelope element information item (see 5.1 SOAP Envelope).

SOAP/1.2 has achieved CR status, and therefore represents a considerable amount of consensus-building and engineering oversight, all of which was conducted in an open, public forum. This makes the prospect of redesigning SOAP to accommodate a new data model is daunting, given the amount of issues that would need to be revisited. Moreover, by abandoning an XML-based data model, SOAP message processors would lose the ability to take advantage of the large and growing infrastructure for describing XML (e.g., XML Schema, Relax NG) and for processing XML (e.g., SAX, DOM, XPath, XSLT, XML Query).

The impact of two data models on SOAP is complicated by the presence of SOAP intermediaries. In both SwA and WS-Attachments, referenced data needs to be processed by SOAP nodes (including intermediaries); currently, such a processing model is undefined. Can referenced data be ignored? Must the order of its appearance be retained at all layers of the stack? How is data targeted at a Node other than the ultimate recipient? Must it be forwarded by SOAP intermediaries? Can SOAP intermediaries add or remove non-Envelope data before relaying a message? Unfortunately, the current SOAP processing rules work at the level of the SOAP envelope and do not provide any guidance on these issues. As a result, every future SOAP extension in an attachments world will need to be aware of multiple data and processing models in order to ensure that they do not violate the differing requirements of each.

The problem of having two data models can also be observed by looking at the dilemma surrounding WSDL/1.1. In addition to providing XML Schema-based facilities for describing SOAP headers and payloads, WSDL/1.1 also attempts to describe multipart MIME messages (see Section 5 of WSDL/1.1). However, this feature received very little attention during the development of WSDL and frankly it shows. Very few members of the Web services community find this feature to be well thought-out or, as a result, interoperable. Furthermore, the integration of the SOAP binding with the MIME binding is underspecified, leaving organizations such as SOAPbuilders, WS-I, and others to each devise their own approaches for describing messages that are "more than SOAP."

4. Flexibility in Representation, Consistency in Model

In contrast, retaining the current XML-based data and processing models for messages considerably reduces complexity. Assuming that all message data belongs to a single Infoset based on SOAP:Envelope requires no changes in the Web services architecture; the current schema/WSDL infrastructure is sufficiently expressive and can retain its simplicity, and SOAP's extensibility mechanism, the SOAP header, is adequate to describe the entire data set. Perhaps most importantly, the work done to establish baseline interoperability at the SOAP envelope layer does not need to be repeated for a new message processing and data model.

Moreover, an Infoset-based approach scales well to a world in which not all technologies can handle new encodings or framing techniques such as SwA, DIME or WS-Attachments. By retaining the pure XML Infoset model currently in wide deployment, any message can be rendered in simple XML 1.0 using UTF-8. This means that technologies such as XML Digital Signature and XML Encryption can be used without modification. More importantly, even in the face of potential new representations of the XML Infoset, all SOAP messages can be represented as UTF-8 text, allowing any SOAP message to survive a purely text-based intermediary (e.g., low-functioning mail system, NOTEPAD.EXE, EMACS).