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

On Feb 16, 2009, at 5:56 PM, Larry Masinter wrote:

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

I don't think we should refuse to engage in a discussion. However, I  
do think the onus is on the XHTML2 WG to make their change workable.  
It's not our job to spring into action every time another spec  
(consciously) comes into conflict with HTML5.

>  Ø  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 believe it is subject to many of the same objections as versioning  
via the DOCTYPE, though not all.

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

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.

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

Assuming a root element attribute does solve this use case, what is  
the value of also having a new MIME type? Are there any use cases  
better addressed by having two mechanisms instead of one?

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

No one has proposed changing the MIME type before, so there isn't  
prior analysis. However, if XHTML5 documents were to be served with a  
new MIME type instead of application/xhtml+xml, they would not  
properly be recognized as XHTML by current XHTML user agents. Our  
Degrade Gracefully principle says, "HTML 5 document conformance  
requirements should be designed so that Web content can degrade  
gracefully in older or less capable user agents, even when making use  
of new elements, attributes, APIs and content models." So it should be  
allowed to send XHTML5 documents as application/xhtml+xml.


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

I also don't think XHTML2 has anything to do with versioning, since it  
is not a predecessor or successor version but rather a separate  
language that's seeking to use the same namespace URI. Any solution  
that's aimed solely at the XHTML2 conflict and not at versioning of  
HTML is not a solution for ISSUE-4.

> It does limit the future path of the HTML serialization to not  
> introduce incompatible changes, but perhaps that’s an advantage.

I expect both the HTML and XML serializations to avoid incompatible  
changes.

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

So what do you do with a .xhtml file?

> metata http-equiv content-type is another way of applying MIME types  
> to content without It being out-of-band.

I don't see why you would ever use a <meta http-equiv> instead of a  
version attribute on the root element if either is allowed.

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

What is unusual about the XHTML1 --> XHTML5 transition that doesn't  
apply to, say the SVG1.1 --> SVG1.2 transition?

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

That's exactly what I did with your proposal.

> Until that analysis is complete, ranking solutions is premature.

I'm open to changing my mind based on new evidence. For now, it seems  
to me that your proposal of new MIME types doesn't solve the problem  
and does introduce some new problems.

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

Granularity of versioning is orthogonal to the means of providing  
version information. DOCTYPE or a root element attribute could be  
either coarse-grained or fine-grained. However, a proposal that  
doesn't distinguish HTML5 from HTML6 does not address many of the  
concerns that led to ISSUE-4 being raised, and so doesn't seem like a  
useful proposed solution for ISSUE-4.

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

That doesn't seem to be a difference between DOCTYPE and MIME type or  
root attribute based versioning.

>
> I particular:
> 	• Distinguishing between HTML2 and HTML5 doesn’t tempt authors to  
> check their documents against the wrong version.

HTML2 is pretty long obsolete, so I don't think anyone is tempted to  
check against it. Assuming you mean XHTML2, then this was not the  
primary concern of the original versioning solutions.

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

Microsoft was tempted to do so for IE. In fact, for a time, they  
demanded addition of a versioning mechanism so they could have  
multiple rendering engines without having to introduce their own  
versioning. That being said, I don't see how this is different between  
MIME type and doctype/attribute versioning.

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

I don't see how this is different between MIME type and doctype/ 
attribute versioning.

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

Again, granularity of distinction being made is independent of the  
carrier of versioning information.

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

I'm not sure that having anything to do with DOCTYPEs is a problem in  
itself, beyond the specific problems it causes.

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

But using a different MIME type doesn't create a way to distinguish in  
all the contexts where it is necessary to do so (e.g. Atom). The only  
way that works consistently in all contexts is to use different  
namespaces. This has to be so, because there are some contexts (such  
as DOM APIs) where the element name and namespace URI are the only  
information available. This means that the (namespace, localname) pair  
alone has to be a unique identifier.

Furthermore, XHTML5 is compatible with XHTML1, so your stated  
motivation doesn't provide a reason to give XHTML5 a different MIME  
type than the one used by XHTML1.

Regards,
Maciej

Received on Tuesday, 17 February 2009 02:31:16 UTC