RE: What's the problem? "Reuse of 1998 XHTML namespace is potentially misleading/wrong"

(I don't know how I managed to attract action items to re-review issues
long since beaten-to-death, but I'm trying to deal with them in good
faith and hoping bring a fresh perspective. Sometimes this means rehashing 
things, I'm afraid.)

> ISSUE-4 is whether or not HTML5 needs a versioning mechanism; the WHATWG 
> position is no.  Those that do feel that there needs to be a versioning 
> mechanism (e.g., Microsoft) seem motivated to find a solution that works 
> with the HTML serialization of HTML 5.

I had proposed closing ISSUE-60, based on a misunderstanding, and
I'm trying to explain why I now think it needs to remain open.

My view was that ISSUE-60 on namespaces could be addressed if there
is a versioning mechanism which can disambiguate between different
languages that share the same namespace (as a possible resolution
to ISSUE-4). If not, ISSUE-60 should remain open with action items
to coordinate between the W3C working groups defining the different
languages which share the same namespace. Note that I am not
proposing that the action item on ISSUE-60 should be "change
the namespace", but rather on coordination.  

Now, as to the decision making process, here: the HTML WG and
the XHTML2 WG may decide separately to go their own stubborn
ways and retain the overlap, but I don't expect the W3C advisory
committee to advise the director, or the director to accept,
two W3C Recommendations which propose incompatible languages,
both with the same namespace, with no mechanism to distinguish
between them, no matter what the working groups themselves wish
were true.

My view on ISSUE-4 versioning is that the reasons given against
versioning in all of the discussion I can find did not include any 
discussion of using versioning to distinguish between different
languages which share the same vocabulary.

Most of the discussion about "versioning" was in fact focused on
the "DOCTYPE" and unsupported speculation on how it might affect
or tempt future implementers, authors, and editors of future
specifications. 

I think my proposal that XHTML5 and XHTML2 use different
MIME types (neither of them application/xhtml+xml), and
that in addition, there be wrapper element(s) that senders
can use in embedded fragments within compound XML documents
stands as a simple proposal which passes most of the previous
objections raised to "versioning":

http://lists.w3.org/Archives/Public/www-archive/2007Jun/0024.html


It doesn't encourage authors to check their documents against
obsolete versions, it doesn't tempt implementors to implement
new rendering engines per version, it doesn't tempt editors
of future versions of the specification to use versioning
as a means of fixing compatibilities, it doesn't make year
to year changes to the "boilerplate", it doesn't have anything
to do with triggering "Standards mode" in browsers, it doesn't
have anything to do with DOCTYPE, etc.

If there's some argument against versioning that I missed,
could someone do me the kind favor of pointing it out?

Larry
-- 
http://larry.masinter.net

Received on Monday, 16 February 2009 23:16:20 UTC