- From: Larry Masinter <LMM@acm.org>
- Date: Thu, 04 Nov 2004 19:19:15 -0800
- To: public-ws-media-types@w3.org
- Cc: Jon Ferraiolo <jonf@adobe.com>
(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, 5 November 2004 03:19:17 UTC