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

> ....  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
of 
>        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.)

Larry