W3C home > Mailing lists > Public > public-ws-media-types@w3.org > February 2005

RE: Comments on http://www.w3.org/TR/2004/WD-xml-media-types-20041102/

From: Larry Masinter <LMM@acm.org>
Date: Fri, 25 Feb 2005 21:20:06 -0800
To: "'Jonathan Marsh'" <jmarsh@microsoft.com>, public-ws-media-types@w3.org
Cc: "'Jon Ferraiolo'" <jonf@adobe.com>
Message-id: <0ICI00EOK6TIAC@mailsj-v1.corp.adobe.com>

> ....  It would be nice for the description to be able to say things like:
> - send me a SOAP envelope (WSDL SOAP binding tells how to do that)
> - make the body look like this (XML Schema element 
>         declaration tells how to do that)
> - embed your encoded binary data here within that structure (XML Schema
>          xs:base64Binary datatype tells you where the binary data goes)
> - and only embed binary data of the types image/jpeg or image/png -
>        don't bother sending me an image/gif because I won't be able 
>        to process it (xmime:expectedMediaType adds this additional layer
>        description).

> The last bit is currently described in english or some out of band
> mechanism.  Xmime:expectedMediaType provides a common machine-readable
> description of this information.  The client can use this description to
> construct the message, right down to indicating (with xmime:contentType)
> that it chose image/png over image/jpeg.
> Which part of this troubles you?

In all of the practical examples I know of, you need to
know more than just the MIME type names. It's the reason
why the W3C Mobile activity continues to develop CCPP
(www.w3.org/Mobile/CCPP/) and why the media feature
registry and expression language of RFC 2533, RFC 2913
were invented.

Perhaps you have some other practical example in mind
where a list of media types alone is actually useful?

I don't think "it would be nice" is strong enough; it's what led to
HTTP accept headers, which seemed like a good idea. (Well, HTTP accept
headers *was* a good idea when there were a limited number of
formats that anything could be represented in, and a limited
number of clients with associated capabilities, and when web resources
were considered single files rather than multiple parts of complex
compound structures.)

Received on Saturday, 26 February 2005 05:20:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:15 UTC