Re: Summary: Encodings other than base64

"John J. Barton" <John_Barton@hpl.hp.com> wrote at Tue, 30 Sep 2003 18:37:46 -0700:
> At 02:10 AM 10/1/2003 +0100, Tony Graham wrote:
> <snip>
> 
> >Arguments against encodings other than base64 are:
> >
> >  - One might take the view that optimizing more than one type
> >    encourages one to send the actual type label as part of the
> >    model. [3]
> 
> Tony, can you elaborate just a bit on the context for "type"
> here?  Are you referring to the format of the object that might
> be base64 encoded (eg image/jpeg) or something in the XML
> space?

I was merely channeling Noah, so you'll have to ask him.

When I was putting that list together, it occurred to me that there
were more meanings placed on 'encodings other than base64' than I was
prepared to unravel at that time of night.

One, which hasn't had much of a run on this list, is the actual
serialization of the binary data behind the notional base64 data in
the infoset of the SOAP message.  The data that MTOM puts in the
non-root body parts of a MIME/Multipart message could, for example,
have a content transfer encoding as quoted printable.  (And if you did
implement MTOM over 7-bit SMTP, that might be a compact form for some
data.)

Another view of encoding that, I think, is a bit off the mark is
talking about encoding the actual type of the underlying binary data.
E.g., as in your example above, stating that the data that is
notionally base64-encoded characters in the infoset has the media type
image/jpeg.

PASWA, for example, only talked about base64-encoded content, and it
separately defined the xmime:MediaType attribute that "specifies the
media type [RFC 2045] of the base64-encoded content of its [owner]
element." [6]

If anything, the current MTOM WD goes the other way: anything that
looks like it could be base64-encoded content could be a candidate for
optimization [7].  Imagine if I put a base64-compatible ASCII-art
picture of the Mona Lisa [8] in an element in a SOAP body; it could
end up in a different MIME/Multipart body part in the serialization
with nothing asserted about either its encoding or its media type
(although some might assert it to be 'image/x-dated').

Note that when Noah proposed base64-specific MTOM text [9], he didn't
change the "if it looks like base64, it can be base64" provision.

That leaves discussing encoding other XML schema types along with
base64-encoded characters.  That topic tends to diverge in three
directions.  The road less traveled is definitely the idea of making
separate MIME/Multipart body parts out of any content no matter what
its type.  Another path leads to discussing allowing optimization of
known types, which leads to discussions of labelling the type of the
data so you know what to optimize, which leads to data models and the
XQuery data model in particular at present [3].  The third path leads
to discussing different serialization forms for different types, which
leads to discussion of binary infosets, which gets very different
reactions from different people [4][10].  However, the binary infoset
workshop was only last week, and the workshop is set to be reviewed
today.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708


> >[3] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0066.html
> >[4] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0071.html
> >[5] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0068.html

[6] http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html#_Toc36994425
[7] http://www.w3.org/TR/2003/WD-soap12-mtom-20030721/#aof-properties
[8] http://www.chris.com/ascii/art/html/monalisa.html
[9] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0067.html
[10] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0072.html

Received on Wednesday, 1 October 2003 08:59:44 UTC