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

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

I added some content for the existing action item, including asking XHTML2 WG to propose a versioning mechanism they would be willing to adopt. So I think I did this.

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

I don't think it matters who starts a conflict: "Teacher, he started it." isn't a good reason to refuse to engage in a discussion of how to resolve a conflict. Yes, it is "our" problem, insofar as our obligation to produce standards that work for the entire community. Yes, it is "our" problem if you look at the needs of the greater community and not a narrow special-interest group.

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

Yes, I like the idea of indicating version in the root element better than using DOCTYPE for many reasons. I don't see any analysis of a version root element (as opposed to a version attribute).  I'd rather have a version root attribute, though, than nothing.

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

I am proposing two mechanisms, not one.
(a)    define different MIME types
(b)   *also* allow a root element/attribute which distinguishes between the types

Ø   Does not solve the compound document use case, which is a case where other versioning solutions fail.

I agree that the MIME type alone is inadequate for the compound document use case.

Ø   Violates our Degrade Gracefully design principle.

I don't understand how new MIME types for XHTML2 and XHTML5 serializations degrade any less gracefully than application/xhtml+xml did. I suppose it makes the Accept headers longer. Maybe you could send me a pointer to some analysis of this?

Ø   Doesn't help with versioning of the HTML serialization.

I don't think XHTML2 has anything to say about text/html, so I'm not sure why this is an issue here.  I am satisfied with a solution that deals with versioning of XML specifications and leaves text/html without any more versioning than the (now deprecated or vestigal) DOCTYPE. It does limit the future path of the HTML serialization to not introduce incompatible changes, but perhaps that's an advantage.

Ø  Hard to apply to contexts such as filesystems where there may not be out-of-band MIME type information.
One could define new file extensions .xhtml2  and .xhtml5 for such file systems.  metata http-equiv content-type is another way of applying MIME types to content without It being out-of-band.

Ø  Out of line with precedent for XHTML and HTML (which have historically reused the same MIME type for new versions).

The fact that the problem wasn't solved in the past shouldn't be a precedent for now solving it now. And XHTML *did* introduce a new MIME type, namely application/xhtml+xml.  The only problem was that XHTML assumed DOCTYPE was an adequate versioning mechanism, when it isn't.

Ø  - Out of line with precedent for other W3C markup languages (ditto).

The situation is unusual. The text/html -> application/xhtml+xml transition was also unusual.

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

You evaluate solutions based on whether they solve the problem and don't introduce new problems. Until that analysis is complete, ranking solutions is premature.

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.

(a)    Most of those arguments were specifically given examples using DOCTYPE with a fine-granularity versioning strategy, rather than a coarse family designation.
(b)   Most of those arguments are merely speculations about the potential encouragement of future behavior, primarily of actors who aren't represented, about "temptations" those actors might be faced with.

I particular:

 *   Distinguishing between HTML2 and HTML5 doesn't tempt authors to check their documents against the wrong version.
 *   Many implementers are on this mailing list: are there any who would be tempted to implement a new rendering engine per version, were there to be a versioning mechanism?
 *   We don't know who will be editors of future versions of the specification, so we can only rely on the current editors: would the presence of a versioning mechanism tempt any current specification editor to use versioning as a means of fixing compatibilities, rather than solving the hard problems? Ian? Michael? Dan?
 *   Since the proposal only suggests distinguishing between HTML5 and HTML2, it doesn't make "year to year" changes, since the spec is slated for update less frequently than annually.
 *   The proposal doesn't mention DOCTYPE or have anything to do with it.

As far as other proposals, well, at a minimum, the DOCTYPE proposal has something to do with DOCTYPE and mine doesn't, so that's a way in which my proposal avoids DOCTYPE problems. So my proposal avoids these problems more than at least one other 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.

I think this is completely hypothetical, in line with "editors of future versions of the specification" prediction. Future versions of XHTML should not be incompatible languages, and the only reason for assigning new MIME types is to avoid having two languages using the same XML namespace with no other way of distinguishing between them.

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