W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2003

RE: Opaque data, XML, and SOAP

From: Eugene Kuznetsov <eugene@datapower.com>
Date: Mon, 10 Mar 2003 16:50:31 -0500
To: "'Anne Thomas Manes'" <anne@manes.net>, "'Don Box'" <dbox@microsoft.com>, <xml-dist-app@w3.org>
Message-ID: <01a101c2e74f$121da300$142ba8c0@EKi4100>

> I certainly prefer the idea of using XInclude better than SwA or
> WS-Attachments. But why not just use base64? It's really the 
> better way to go.

Base64 is simply not practical for large chunks of binary data.
Processor cycles and bandwidth are not free, contrary to popular belief.


Several usecases:

1. large media files that dwarf the size of the SOAP message that
carries them

2. intermediaries that do not need to consume the entire contents of a
message -- but could be forced to scan, transmit and copy megabytes of
base64 

Here is another suggestion, one that is quite half-baked: in an ideal
world, where we could add extensions to XML syntax itself or piggy-back
on existing extensions (entities, PI's, CDATA, etc.), is there anything
that would be better than base64 but still allow binary data to be
embedded?

Seems that some of the wishlist may be: 1. ability to have length-based
chunking rather than delimiter-based processing 2. no excessive bloat 3.
easy to apply XML DSIG and other processing to embedded binary data.

The deeper issues here go to the basic conflict between delimer-based
and length-based formats, but perhaps some outside-the-box thinking is
called for here. 

\\ Eugene Kuznetsov
\\ eugene@datapower.com
\\ DataPower Technology, Inc.
\\ http://www.datapower.com - XS40 XML Security Gateway
Received on Monday, 10 March 2003 16:50:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:13 GMT