Re: Optimisations other than Base64

Martin Gudgin wrote:
> MTOM provides for a specific kind of optimization, namely serializing
> particular things as raw binary in separate parts of a multipart/related
> package. I think the notion of a binary XML is in a completely different
> space.

I wouldn't so radically separate them. As I understand it, MTOM defines a 
mechanism to include "external data of any type in an XML Infoset", where any 
type includes binary (I'm unsure about the "external" in there, but that's a 
minor nit). It then describes a way of serializing that in a multipart/related 
message.

However it doesn't appear from the latest WD that that serialization has to be 
the only one -- in fact I'd consider the most important step the clearer 
relationship between the Infoset and binary data, something which was unclear 
for a while and absent from early PASWA works.

We have experimented with direct inclusion of binary data in the Infoset in SVG, 
based on data: URIs which it mandates (eg <svg:image 
xlink:href='data:image/png;base64,....'/>). The results were quite encouraging 
since using our low level API (that sits below the SAX interoperability layer) 
we were able to get obvious speed gains over the original 
UnicodeWithAngleBrackets SVG.

MTOM seems to carefully avoid ever saying that it is solving an XML packaging 
problem, perhaps for fear that the old XML Packaging spectre will leap out of 
the shadows and call for a more generic set of solutions (the word "packaging" 
appears several times, but always as "MIME Multipart/Related packaging").

Since binary infosets do target solutions in the XML packaging space, and since 
binary data in the Infoset does address a number of previously existing issues 
also in that space, I find it hard not to see a very possible relationship :)

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Wednesday, 30 July 2003 10:01:41 UTC