XML, SOAP and Binary Data(2)

These performance concerns have discouraged many developers from using embedded data in XML. It is interesting to note, however, that XML Schema defines the value space of the base64Binary and hexBinary data types as the actual octets. This makes it is possible to reduce or eliminate the size and performance costs of base64/hex decoding in many common scenarios (e.g., in-memory DOM trees, SAX pipelines, etc). However, this is not the case when the XML is serialized as UTF-8 or equivalent due of the nature of XML 1.0.

2.2 Referencing

XML 1.0 explicitly supports referencing external opaque data as external unparsed general entities. Considered a fairly esoteric feature of XML, unparsed entities are not widely used. The primary obstacle to using unparsed entities is their heavy reliance on DTDs, which impedes modularity as well as use of XML namespaces. They are also not available to SOAP, which explicitly prohibits document type declarations in messages.

A more common way to reference external opaque data is to simply use a URI as an element or attribute value. XML Schema supports this explicitly through the xs:anyURI type.

<?xml version="1.0" ?> <data> <photo data="http://example.org/me.jpg" /> <sound data="http://example.org/it.wav" /> <hash data="http://example.org/my.hsh" /> </data>

An XML schema can describe the content of the data attribute:

<xs:attribute type="xs:anyURI" use="required" />

as can RELAX NG:

<rng:attribute datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <rng:data type="anyURI" /> </rng:attribute>

Often (and especially in Web services), referenced opaque data is bundled alongside the XML, using a packaging format. Soap with Attachments, for example, was inspired by M/HTML [rfc2557], which describes a technique to bundle cached resource representations with HTML documents using multipart MIME. In fact, very little of SwA Section 3 (the meat of the spec) is dependent on the use of SOAP, except in name only. In brief, SwA says the following:

The following example shows a SOAP message that uses SwA:

MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<mymessage.xml@example.org>" Content-Description: A SOAP Envelope with my picture in it --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <mymessage.xml@example.org> <s:Envelope xmlns:s='http://www.w3.org/2002/12/soap-envelope' > <s:Body> <m:data xmlns:m='http://example.org/stuff' > <photo data="http://example.org/me.jpg" /> <sound data="http://example.org/it.wav" /> <hash data="http://example.org/my.hsh" /> </m:data> </s:Body> </s:Envelope> --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-Location: 'http://example.org/me.jpg fd a5 8a 29 aa 46 1b 24 --MIME_boundary Content-Type: sound/wav Content-Transfer-Encoding: binary Content-Location: 'http://example.org/it.wav b1 d7 1f a3 62 53 89 71 --MIME_boundary Content-Type: binary/hash Content-Transfer-Encoding: binary Content-Location: 'http://example.org/my.hsh 15 a6 bb bd 13 a2 d9 54 --MIME_boundary

Referencing opaque data avoids some of the performance and bloat issues associated with base64/hex encoding, but introduces its own problem; because the data is external to the document, it isn't part of the message Infoset.

3. When Worlds Collide

The approach taken by both SwA and WS-Attachments leads to a situation in which there are two data models associated with a message; one that is based on XML and one that is not. This means that layered technologies for processing and describing XML and SOAP need to provide one set of solutions for the XML component of their data and another set of solutions for the external components (e.g., DIME, multipart MIME). Nowhere is this duplication of effort more apparent than in the area of security.

The industry is rapidly adopting XML-based security mechanisms such as XML Digital Signature, XML Encryption, and WS-Security. These technologies were designed for use with the XML data model (and in the case of WS-Security, the SOAP data model). When a second data model is present (e.g., multipart MIME, DIME), additional (and yet to be specified) measures must be taken to ensure the integrity and confidentiality of the non-XML data. For example, a digital signature over a SOAP envelope does not necessarily protect any data referenced by embedded URI. While it is possible to protect this data through additional hashes over the referenced octets, aspects such as MIME or DIME headers are likely not covered by such additional effort. In all likelihood, securing these headers would mean resorting to transport-level security (e.g., SSL) and/or S/MIME, neither of which is robust in the face of XML that is shared by multiple parties or by means other than a simple end-to-end network connection.