RE: ISSUE-4: Versioning, namespace URIs and MIME types

> 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