

XHTML namespace, DOCTYPE, and other versioning mechanisms

From: Larry Masinter <masinter@adobe.com>
Date: Mon, 16 Feb 2009 12:33:38 -0800
Message-ID: <8B62A039C620904E92F1233570534C9B0118C8658F40@nambx04.corp.adobe.com>
In reply to various messages:

>... unless I'm missing something the doctype issue won't help with 
> the use case of compound documents (say HTML used in <svg:foreignObject> 
>  no matter what.  You can't put a doctype inside <svg:foreignObject> 
> because that wouldn't be well-formed XML.

Yes, I agree; DOCTYPE doesn't seem to help much.

> ... since user agents in practice support XHTML namespace  
> elements in arbitrary XML compound documents

The fact that some software implements something (table summaries or
header profiles, for example) hasn't been given as strong a weight
in this group as the actual practice in real documents on the web.
Is there actually any significant deployment of real web content that
uses XHTML namespace elements in arbitrary XML compound documents?

If we are giving weight to implementation impact, we should give
the weight equally.

>  Further, since user agents in practice support XHTML namespace  
> elements in arbitrary XML compound documents, this would amount to  
> requiring XHTML5 user agents to implement XHTML2, which is not a  
> reasonable requirement.

Requiring that senders identify the language they're using does
not require that receivers be able to interpret every language
a sender might send.

> As for XHTML5 and incompatible changes, those would in fact need to be 
> avoided, as they have generally been for HTML, unless we have a 
> per-element versioning scheme in place....

The per-element versioning scheme has been the norm, either by adding
new elements or new attributes or new ways in which old elements can
be combined that were previously not supported and are supported now.

I think a specific element/attribute combination seems like the
only choice given the reasons for keeping the same namespace for

I've read about a version="" proposal as an attribute, but that
seems like a poor device specifically *because* of the need to
promote versions.

As an aternative, we could ask that, if XHTML2 keeps the same 
namespace as XHTML1 and XHTML5, that all XHTML2 fragments be
identified by wrapping them in an <xhtml2> element.  We could 
require that HTML user agents that do not support XHTML2 not 
attempt to interpret <xhtml2>-wrapped content any more than 
they would attempt to treat SVG content as HTML.

> HTML 4.01 differs from HTML 3.2 and XHTML 1.0 yet all three can be  
> served with the text/html MIME type.

The XHTML 1.0 specification was careful to *not* allow
text/html except in transitional cases. So saying that
"XHTML 1.0 can be served with the tex/html MIME type"
is misleading.

MIME type labeling is a way of a sender to communicate to
a receiver the identity of the language of the message --
i.e., how the sender wishes the receiver to interpret
the message. This language identification process has
meaning, independently of the advice you might give
senders on how to label their message so that receivers
are likely to understand it, and independent of the
advice you give to receivers on how to deal with the
reality of mis-configured senders.

> More importantly, though, user  
> agents will likely process application/xhtml+xml (and indeed  
> application/xml or text/xml) documents under XHTML5 processing rules  
> rather than XHTML2 or XHTML1, so the new MIME type won't provide  

If there is no chance that the implementers of user agents
might actually listen to the advice of the consensus of
members of "public-html@w3.org", then there's no point
in this conversation at all. 

So I'm unsure how much weight to give to an independent
prediction of what "user agents will likely process"
as input to what it is that the committee should recommend
to user agents.

And of course, there are more players in the tool chain than
"user agents". 

Can you make this argument in a less circular form?

Received on Monday, 16 February 2009 20:34:26 UTC
