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

On Feb 17, 2009, at 10:47 AM, Larry Masinter wrote:

>>> I am proposing two mechanisms, not one.
>>> (a)    define different MIME types
>>> (b)   *also* allow a root element/attribute which distinguishes
>>> between the types
>
>> In that case, I'd point out that using a new MIME type in addition to
>> a distinctive root element/attribute in the markup doesn't add
>> anything relative to just doing the latter. And it retains some of  
>> the
>> downsides I cited. So I still don't think it is a very good solution
>> for ISSUE-4.
>
> Argument for two versioning mechanisms rather than one:
>
> Language components without distinctive root element/attributes
> or even namespaces at all can be passed around unchanged, given
> sufficient contextual information about which language was
> intended. The MIME type supplies that contextual information.
> When embedding one document in another, the contextual information
> needs to be made explicit. Having both mechanisms adds complexity
> but allows both nested content and also uniform content without
> any explicit versioning information.

But usually it is precisely when nested fragments are transmitted that  
no MIME type is available. And even when a MIME type may be sent in  
such cases, using a currently unknown MIME type is likely to lead to  
content that won't degrade gracefully in existing UAs. For example,  
Atom <text> elements have a MIME attribute that may only be "xhtml",  
"html" or "text". Atom <content> elements may specify a MIME type, but  
XHTML is treated as a special case and the MIME type is given as  
"xhtml". Using a custom MIME type will not display content the same  
way in existing feed readers. The SVG <foreignObject> element does not  
allow a MIME type for the embedded fragment to be specified at all.  
These are probably the two most common cases where XHTML fragments  
will be embedded in another XML language. 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?

> 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 desgin principle, even if it is optional.

> 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?

Regards,
Maciej

Received on Tuesday, 17 February 2009 19:59:31 UTC