W3C home > Mailing lists > Public > public-html@w3.org > February 2009

ISSUE-4: Versioning, namespace URIs and MIME types (was Re: What's the problem? "Reuse of 1998 XHTML namespace is potentially misleading/wrong")

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 16 Feb 2009 16:12:33 -0800
Cc: Sam Ruby <rubys@intertwingly.net>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>
Message-id: <0EB901F6-FF79-4B86-8A44-E1B4E8BECDD6@apple.com>
To: Larry Masinter <masinter@adobe.com>


Changing the subject, since this isn't entirely on the original topic  
any more.

On Feb 16, 2009, at 3:15 PM, Larry Masinter wrote:

> (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.

Would you be willing to propose some specific actions that you think  
would resolve ISSUE-60, or particular things we could do to make  
progress?

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

I think describing the situation as the working groups "decid[ing] to  
go their own stubborn ways" is a misleading characterization. What  
actually happened is that there was no conflict (since the specs used  
different namespaces) and then the XHTML2 WG chose to change their  
namespace URI, thereby creating a conflict, and notwithstanding input  
that this could be a problem. I don't think that makes it our problem,  
and I doubt the Advisory Committee would see it that way either.


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

It's true that this particular case was not considered in prior  
discussions, which is why I proposed making a note of it under issue  
4. You should have every opportunity to make the case for the  
importance of 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.

Besides DOCTYPE, an attribute on the root element was also considered.  
Here's an email where I compared the two approaches and showed why a  
version attribute was strictly superior to DOCTYPE versioning:

http://lists.w3.org/Archives/Public/public-html/2007Apr/1053.html

I think this was pretty conclusive as to the preferability of a  
version attribute, although there was still much subsequent argument  
on whether to have versioning at all.


> 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

I think your proposal of using the MIME type for versioning has some  
serious downsides:

- Does not solve the compound document use case, which is a case where  
other versioning solutions fail.
- Violates our Degrade Gracefully design principle.
- Doesn't help with versioning of the HTML serialization.
- Hard to apply to contexts such as filesystems where there may not be  
out-of-band MIME type information.
- Out of line with precedent for XHTML and HTML (which have  
historically reused the same MIME type for new versions).
- Out of line with precedent for other W3C markup languages (ditto).

So I do not think changing the XHTML5 MIME type is a very strong  
proposal for ISSUE-4. I would personally rank it below both the  
DOCTYPE and version attribute proposals.


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

I'm not sure how your proposal avoids these problems more so than any  
other versioning proposal. If XHTML6 (or 5.1) changes the MIME type  
yet again, then all of these same issues arise. If it does not, then  
none of the perceived benefits of versioning are gained either.

Regards,
Maciej
Received on Tuesday, 17 February 2009 00:13:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC