[
Lists Home |
Date Index |
Thread Index
]
On Friday 10 May 2002 13:53, Thomas B. Passin wrote:
> True (see SOAP+attachmemts). XML is a good candidate for sending
> metadata about binary data.
>
> As in MPEG-7, if I understand things right.
But why does any data need to be 'binary'? XML is an interchange format, but
it falls apart for certain types of information such as images... large
arrays and so on. Other interchange formats don't. You can encode images in
PER quite happily, it's just a "SEQUENCE OF SEQUENCE OF SEQUENCE { red
INTEGER, green INTEGER, blue INTEGER }" from memory (might want to constrain
those R/G/B integers into a sensible range to make them one or two bytes
each).
Those giant arrays can fit seamlessly in with the "SEQUENCE OF Paragraph"
describing the image to humans and the "ImageInformation ::= SEQUENCE { name
UTF8String, width INTEGER, depth INTEGER }" and be processed with the same
tools. You can pull out the colour of the top left pixel of the image with
what passes for XPath in ASN.1-land.
It strikes me as lame that, in XML, certain types of information need
seperately defined 'binary' file formats designed for them and to be bundled
with the XML in "some way" and referenced in "some way" - in emails, MIME
with cid: URLs; or in a ZIP file or directory or HTTP/FTP-reachable directory
with relative URLs.
If you're doing SOAP, you'll have to put up those 'binary attachments' on an
HTTP server somewhere and embed the absolute URL in the message, and decide
*somehow* when the recipient's not likely to want to look at it any more to
remove those attachments from the HTTP server. Ugh.
Seems *ugly*!
The only time when *information* is really binary is when you're doing
cryptography, as far as I can tell! The rest of the time it's just binary
data which encodes some kind of information - a description which XML itself
fits!
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
