> A couple of weeks ago on this list, there was a thread that was
> lamenting the slow adoption of XML in the web community.
>
> It seems to me that one of the first problems programmers
> encounter is XML's inability to handle "binary" data. Once they
> hit that wall, they drop XML and move on to something else
> (usually a custom format).
>
> If we could turn back the clock to before 19980210 and get
> rid of design goal #3, handling binary data could have been
> so easily handled by adding one element attribute. If the
> XML spec had included one predefined attribute called
> "xml:length" binary data would have been a no-brainer to
> handle. Here's an example:
>
> <BINARY_DATA xml:length="4"><<<<</BINARY_DATA>
This suggestion has a few problems. What does 'xml:length' represent
-- bytes or characters? How can a program change the encoding (say,
from UTF-8 to UCS-4) without actually parsing the document? If I'm
transmitting from an M68K to an 80*86 machine, what happens to byte
order?
When you do need binary data inline, here's a much simpler solution:
<BINARY_DATA type="text/plain" enc="base64">PDw8PA==</BINARY_DATA>
You can easily add attributes for the length, checksum, digital
signature, encryption key, etc.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/