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

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