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

We've been looking at your comments, and expect to provide full
responses shortly.  But let me explore your primary concern in order to
help our WG discussion move forward.

Would you have the same objection if, instead of Accept-headers, we
simply provided a list of expected media types, with no parameters or
wildcards?  E.g. xmime:expectedMediaType="image/jpeg image/gif
image/png".  This would address, if I understand it correctly, your
concern that wildcards lead to incorrect assumptions about the
capabilities of the parties involved.  Namely, "how can you assert that
you accept image/mynewimagetype when I haven't even invented it yet?"

> -----Original Message-----
> From: public-ws-media-types-request@w3.org [mailto:public-ws-media-
> types-request@w3.org] On Behalf Of Larry Masinter
> Sent: Thursday, November 04, 2004 7:19 PM
> To: public-ws-media-types@w3.org
> Cc: Jon Ferraiolo
> Subject: Comments on http://www.w3.org/TR/2004/WD-xml-media-types-
> 20041102/
> 
> 
> (1) I'm suspicious of the attempt to use HTTP "accept" headers
> to "indicate in XML Schema what media
>    type the character content of an element will have."
> 
> In practice, HTTP Accept headers have turned out to have
> severe interoperability problems, and have not been useful
> for content negotiation. It's a bad practice to try to
> follow something that hasn't worked for the stated purpose.
> For example, a description of "image/*" is, in practice,
> not useful because of the wide variety of image types
> that are likely *not* implemented.
> 
> In general, indicating ranges of acceptable media type
> is quite difficult; the best practice in this area is
> likely to be either CCPP (www.w3.org/Mobile/CCPP/)
> or media feature expressions (RFC 2533 plus
> RFC 2913). However, neither have widespread deployment
> and interoperability experience.
> 
> ================================
> (2) I think the document suffers from an editorial
> problem which starts with the title. "text/xml;charset=utf-8"
> is not a "IANA media type" or a "media type token", it
> is a "content-type string", the difference being that
> a content-type string starts with a media type followed
> by parameters for that type.
> 
> I think it's important to avoid confusion by careful
> editing:
> 
> - The title: "Assigning Media Types to Binary"
>   probably should be "Describing Media Content of Binary"
> 
> - The schema definition could be 'expectedContentType'
>   instead of 'expectedContentType' (if a single value;
>   if a more complex type expression language is allowed,
>   then rename accordingly).
> 
> - "Declaring media types for binary data"
>   => "Declaring Content-Type for binary data".
> 
> - "the name of an IANA media type token" =>
>    "a valid content-type string"
> 
> =========================
> (3) "[normalized value]": I think defining a normalization for
> content-type strings is difficult, and you should avoid it.
> 
>

Received on Friday, 25 February 2005 20:59:38 UTC