- From: Larry Masinter <masinter@adobe.com>
- Date: Tue, 17 Feb 2009 12:50:38 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- CC: HTML WG <public-html@w3.org>
> But usually it is precisely when nested fragments are transmitted that > no MIME type is available. I thought the paragraph you were responding to agreed with your statement, so I'm not sure why you used "But" here. > Atom <text> elements have a MIME attribute that may only be "xhtml", > "html" or "text".... I'd go through your email line by line, but I think in general you are using the term "MIME type" incorrectly, and thus it makes discussions difficult. Certainly, "xhtml", "html", "text" are not MIME types. MIME is specified in six RFCs: 2045, 2046, 2047, 4288, 4289 and 2049. I think the intent in saying "MIME type" is to reference http://en.wikipedia.org/wiki/Internet_media_type for which http://tools.ietf.org/html/rfc4288 is a reasonable reference. In general, many specifications have not clearly explained whether they are asking for a Internet Media Type (the two-part identifier, like text/html or application/xhtml+xml) or a Content-Type header value (which can include parameters.) It is unfortunate, but the Atom and SVG specifications also fail to be clear about the relationship of their use of type designators and the semantics applied. > Atom <content> elements may specify a MIME type, but > XHTML is treated as a special case and the MIME type is given as > "xhtml". Again, "xhtml" is not a "MIME type" or a "Content-Type" or anything other than a value in a fixed vocabulary. > Using a custom MIME type will not display content the same > way in existing feed readers. I think there is some misunderstanding about MIME types or content-type strings which is endemic and probably requires discussion, which is also relevant to the "MIME type sniffing" argument. Content-Type and MIME types are methods for senders (authors, web servers, agents) to communicate the intent of a communication to receivers (browsers, search engines, etc.) A given piece of content does not intrinsically "have" a MIME type or a content type. So a given string of text may legitimately be sent from a server to a client labeled as "text/plain" ("Please treat this as plain text") or "text/html" ("Please treat this as HTML of some version") or "application/xhtml+xml" ("Please treat this as XHTML of some version) or possibly -- just for the sake of discussion -- as "application/xhtml5+xml" ("Please treat this as XHTML version 5). A receiver, seeing some content with some label, should do the best it can to satisfy the needs of the user of the receiver to interpret the content as sent by the sender. We can give advice or recommend conformant behavior for both senders and receivers in this distributed communication scenario, but a useful way of dividing the specification would be in three parts: (a) what are the sets of strings and what do they mean (the technical reference) (b) what is good advice to implementers of senders to accomplish interoperability with deployed receivers (applicability statement) (c) what is good advice to implementers of receivers to accomplish interoperability with deployed senders (and content). (applicability statement) > The SVG <foreignObject> element does not > allow a MIME type for the embedded fragment to be specified at all. Yes, MIME types are only appropriate for entire message bodies, and are not generally used for embedded content. (Not generally, but there are exceptions, for example the data: URI scheme http://tools.ietf.org/html/rfc2397 includes a content-type string and a way of embedding arbitrary content labeled with a content-type string.) > These are probably the two most common cases where XHTML fragments > will be embedded in another XML language. I'll accept those as the first examples out of the gate. I think the versioning issues are likely also to hit with web mail, for example, if GMail wants to display in an XHTML5 web page the content of a message with XHTML2 content, there might also be mutual embedding. > Can you describe any likely > scenario where an XHTML fragment is embedded, but a MIME type of > "application/xhtml5+xml" could safely be used to label it? (a) I don't think "data:" is likely, although it would be "safe" at least from the position of clearly identifying the content. (b) I didn't propose using MIME types to distinguish content in the case of direct embedding of one XML language within another. >> I think the "downsides" can be avoided by making the appropriate >> choice, and that the choice is available with appropriate >> processing. > I continue to think a new MIME type for XHTML5 violates the Degrade > Gracefully design principle, even if it is optional. Currently, your writing about "MIME type" indicates to me that you have a different model than the one I outlined above for what a "MIME type" means and how it is used, and that getting straight about the context of use of "MIME types" would help bring more clarity to the discussion, so that we're not using the same terms with different meanings. >> I suppose we'll need to go through some use cases and scenarios to >> verify that, though. > Shouldn't we be doing that before strongly advocating new proposals, > rather than after? In short, no. Since this is a process question, I will refer you to the January 8 teleconference minutes: http://lists.w3.org/Archives/Public/public-html-wg-announce/2009JanMar/0007.html which reviewed ISSUE-4, and in which I volunteered to take an action-93 to review the material on DOCTYPES and versioning and report back. My report is that there are some considerations about DOCTYPE and versioning that were not in the readily available material discussing the issue (such as interaction with scripting, and deployment of mixed languages which include XHTML fragments in other XML languages, and so forth) and there are some possible mechanisms for versioning which do not look like they have been explored. I am not "strongly advocating" new MIME types, I am only advocating that versioning remains a problem, that there are possible solutions that haven't been explored, and that work on this issue could continue in a reasonable way, if committee members are prepared to discuss the technical issues in good faith. I don't think it was a requirement, in order to complete this action item, that I also complete the analysis of the alternate possibilities that I'm raising. Regards, Larry -- http://larry.masinter.net
Received on Tuesday, 17 February 2009 20:51:18 UTC