Re: Opaque data, XML, and SOAP

ICE (www.icestandard.org) has been handling binary data in XML messaging
for years quite nicely, so while I agree that technically speaking XML
can't directly contain raw binary data, it's pretty obvious that there are
many messaging scenarios that need to involve binary data, and there are
reasonable means to do so. The mechanisms used by ICE are:

- inline: base64 encoded (so that it can't contain the CDATA terminator).  
This is bloaty, but has the advantage of being inline. 

- by reference: indicate the URL and other access rules in an XML data
structure. ICE can communicate things such as "retrieve the resource via
FTP from this URL, with that username and password, valid for the next 24
hours"). 

- ICE 2.0 is adding the concept of including content by link. That is, a
URL like the reference, but intended to be linked to dynamically rather
than copied locally by the recipient. This could be used for distributing
links to dynamic data (e.g. current weather, a bulletin board) where
there's value in the syndication of the information, but no need to
actually replicate the data.

- In addition to binary data, ICE also supports well formed XML data.

All of the above (in ICE 2.0) are handled through a single generic 
mechanism. That is, there's an element (item) that represents a thing 
being syndicated (e.g. a photo, an article), which contains either a 
reference, an inline object, or a link. So when processing an ICE message, 
the contents can be retrieved generically by a handler for the item 
element that does what it needs to and returns the object, so the location 
of the objects being transported is opaque to the upper layers of the 
application.

There's another option, wrapping the XML message and the binaries as MIME
parts, with a mechanism allowing URL's in the XML to refer to the MIME
parts. ICE doesn't do this, but I believe that some other folks use this
trick. In practice I think that it works out about the same as the base64
encoding (MIME encoding is about the same amount of work); MIME is more
complex than base64, but since there are existing MIME unpackers
available, the complexity may not matter to implementers.

The point of all of this is that since there are many fairly simple 
mechanisms for handling binary data in XML messages, and they've been in 
widespread production for a couple of years now, so I can't agree with the 
assertion that XML can't be used with binary data.

- LP

On Tue, 11 Mar 2003, Elliotte Rusty Harold wrote:

> 
> At 12:13 PM -0500 3/11/03, Marc Hadley wrote:
> >+1. IMO we need a standard mechanism for 'abstractly including' 
> >binary data in an infoset. By 'abstractly including' I mean that the 
> >data is included in an abstract sense rather than included literally 
> >as CIIs. 'Binary smart' processing can take account of the abstract 
> >inclusion, existing processing can ignore it.
> 
> 
> I don't think we need that. In fact, I think we don't need any way to 
> include information in the Infoset that cannot actually be part of a 
> genuine XML document, and I find such attempts damaging and hostile 
> to XML.
> 
> SOAP may have a need to include binary data in its processing. If so, 
> then it needs to build on top of something other than XML and the XML 
> Infoset. XML is not appropriate for all uses.
>

Received on Tuesday, 11 March 2003 13:32:59 UTC