XML, SOAP and Binary Data(4)

This suggests that the correct approach to handling opaque binary data in XML is that of encoding; that is, representing such data within the Infoset using the xs:base64Binary or xs:hexBinary types. However, as discussed, there are potential performance issues surrounding this technique.

How, then, can one keep the Infoset model consistent without encountering these drawbacks? We believe that the answer lies in standardized transformations of the Infoset, or in representations of it. In this fashion, the message can be considered as an Infoset, yet avoid the penalties of actually encoding and decoding the data with base64 or hexadecimal text.

To illustrate this, consider the XInclude [XInclude] mechanism, which allows one to create a synthetic Infoset by merging two Infosets, or by merging plain text content into an Infoset. This latter use provides for an interesting possibility; what if XInclude were to allow inclusion of binary data, to be transformed to base64 or hexBinary-encoded data in the resulting synthetic Infoset? This would allow binary data to be integrated into the Infoset whilst still being serialized as raw octets.

Yet another approach would be to define an alternate serialization of the Infoset (much as WBXML [WBXML] has done) that serializes xs:base64Binary and xs:hexBinary typed data as the actual octets, rather than text-encoded octets. One can easily imagine on-disk/on-wire representations that allow opaque data to coexist as raw octets with the encoded characters of the surrounding XML structured data.

These are only two examples of how one could preserve the Infoset and avoid the performance issues associated with base64/hex text encoding. They are not fully specified here, but serve to illustrate that viable alternatives to current approaches exist and should be considered before radically changing SOAP and Web services.

5. Conclusions

Retaining SOAP's tradition of purely Infoset-based messages has various advantages:

The authors of this paper believe strongly that that data and processing model for SOAP has always been and should remain purely XML-based. Literally thousands of man-years have been directed at defining and refining an architecture based on these assumptions. Moreover, the data and processing model for SOAP should deviate as little as possible from the current SOAP/1.2 Candidate Recommendation.

The authors also believe that the XMLP WG charter allows sufficient freedom in associating opaque data with SOAP Messages to define a SOAP specific processing model, including the XInclude approach, as well as participating in or leading other approaches.

6. Acknowledgements

This white paper is the result of ongoing conversations with:

Erik Christensen, Chris Fry, Yaron Goland, Chris Kaler, Andrew Layman, Hal Lockhart, and John Shewchuk.

7. References [soap11] "SOAP: Simple Object Access Protocol 1.1," W3C Note, May 2000. [soap12wd] "SOAP Version 1.2," W3C Working Draft, July 2001. [soap12cr] "SOAP Version 1.2 Part 1: Messaging Framework," W3C Candidate Recommendation, December 2002 [XInclude] "XML Inclusions (XInclude) Version 1.0," W3C Candidate Recommendation, September 2002 [XML] "Extensible Markup Language (XML) 1.0 (Second Edition)," W3C Recommendation, October 2000 [WBXML] "WAP Binary XML Content Format," W3C Note, June 1999 [rfc2045] "Base64 Content-Transfer-Encoding," RFC 2045, Section 6.8, IETF Draft Standard, November 1996 [rfc2557] "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)," RFC 2557, IETF Proposed Standard, March 1999

1 to 1 of 1

. . . and?
2003-02-26 22:42:44 W. E. Perry

. . . and?
2010-08-29 23:17:44 lonpair789

1 to 1 of 1

，战歌网