Binary Data in XML : Turning back the clock

Jonathan A. Borden jborden at
Wed Sep 30 16:54:21 BST 1998

Binary data is 'junk' only if it lack sufficient metadata to make it
understandable. We work with medical images which are have an inherent and
important binary component (pixels). Base64 encoding is perfectly fine
except when documents raise to the 40Mb and upward size (same for video and
audio clips). At some point there is a really need to work with real binary
data and techniques to integrate binary data with XML data and XML metadata
are important for the adoption and practical use of XML by a wide community
(i.e. the web).

MIME integration with XML solves this problem as well.

Binary data can be incorporated with XML using URI links. The
multipart/related MIME type allows inline transmission of XML and binary
parts using the "cid:pixels-here" URI which binds to the part having the
Content-ID: pixels-here.

multipart messages have served the SMTP community well and work in practice.
Any self respecting SMTP client doesn't try to display parts it doesn't know

Jonathan Borden
JABR Technology
mailto:jborden at
> Second, recall that binary junk is what we are running away from.
> Consider:
> <ms:word xml:length="10000 bytes"></ms:word>
> Yuck! I will rue the day I crash "vi" or "more" by looking at an XML
> document.
> I think that it is a much better practice to have the XML document contain
> only human-readable, human-editable text and LINKS to necessarily
> non-readable stuff. I suppose I would make an exception for streaming
> processes that want to interleave tags and data: base64 handles this fine.
>  Paul Prescod  -

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list