Eddie Sheffield eddie.sheffield at
Mon Dec 14 19:15:29 GMT 1998

roddey at wrote:

> "For example, assuming MIDI data is binary, it might carry two notations.
>  The first would indicate that it is base64-encoded -- remember that this
> is still character data -- and the second would indicate that it is MIDI
> data.  Based on the first notation, the application would pass the
> character data to a base64 decoder to translate it to binary.  Based on the
> second notation, the application would pass the now-binary data to a MIDI
> application, which could play it for your enjoyment."
> Just from a practical standpoint though, if you found an element that had
> say three notations. One said it was MIDI, one said it was Base64, and one
> said it was zipped. Was it base64'd then zipped, or zipped then base 64'd?
> How would one indicate the ordering of original transformations in such a
> situation, so that it could be untransformed correctly back?

Technically, you have a good point. And in some instances it could be a major
issue. In practice, this might not be too big of a concern in most instances just
because of usual conventions. In your example, the base64 would almost by
definition be the last transform done because that's how it was made easily
transportable via a text (XML) file. Just like an email attachment, you don't
base64 then zip - it defeats the purpose of the base64 encoding. Likewise with a
zip notation. Zipping is usually the last step before preparing a file for
archiving or transport (subject to a transport encoding like base64). Of course,
all this means nothing to a parser, but to an application that understands the
notations at all, it would have to be assumed that the application understands an
expected encoding transformation sequence as well.

For those applications where it would be a problem, perhaps some kind of nesting
of elements would be possible, each indicating the encoding of the next nested

Eddie Sheffield

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