Lists Home |
Date Index |
- From: "Eddie Sheffield" <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 14 Dec 1998 14:11:48 -0500
> "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
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)