RE: ISSUE-4: Versioning, namespace URIs and MIME types

On Wed, 18 Feb 2009, Larry Masinter wrote:
> I said:
> > I'm discussing whether there is to be a standard way of indicating which 
> > mode is intended or desired
> 
> Ian replied:
> > Doesn't HTML5 already define the standard methods for user agents to 
> > determine which mode to use? I'm confused.
> 
> We've gone over this difference in perspective multiple times:
> * The question was about a "way of indicating" (for authors);
> * the reply was about a "methods for user agents" (for browser
>  implementers).

As far as I can tell, it documents the author method for indicating the 
mode for all the modes that are considered conforming (XML vs HTML) and 
the user agent method for detecting the mode (not just for browsers) for 
all four modes.

Presumably we would not _want_ to have a conforming way for authors to use 
quirks and limited-quirks mode, since they are of limited use -- they have 
erratic behaviour, do not provide any additional features, and, possibly 
worst of all, trigger modes that certain browser vendors have said they 
have no intention of ever fixing bugs in again, whatever the standards 
ever say.

(See also what Boris wrote.)


> The difference between the question and the reply is whether the way of 
> indicating versions is part of the conforming "language" (it isn't now) 
> and whether there is useful guidance for authors or producers (there 
> isn't now).
> 
> Does this help with the confusion?

Why would we want to make them part of the language?

There is guidance; in what way is it not suitable?


> b) "mode inheritance" for scripts executed within modal implementations
>    would allow DOCTYPE or version attribute or element indicators to
>    disambiguate the intended mode of a script-created document.

As previously noted, scripts do not necessarily execute within the context 
of a mode.


> > (Unless you are talking about modes that are intended to be 
> > non-conforming and not used, in which case they don't need to be 
> > available. This is the case with the quirks and limited-quirks modes 
> > we have currently.)
> 
> It's an illusion to document and specify a mode and then label it 
> "non-conforming and not used". Interpretation modes in receivers are 
> dialects in senders. If you have modes, you have versions.

I didn't say they weren't used, I said they weren't intended to be used.

I disagree that merely documenting how something is implemented suddenly 
makes it a dialect. The descriptive parts of the specification have no 
relevant practical effect on authors as far as the modes go, as far as I 
can tell. The implementations existed before the spec.


> The 16-year-old discussion I pointed to was specifically about the 
> relationship of MIME registration and versioning, and as a counter to 
> your apparent dismissal "we discussed this two years ago". Just pointing 
> out that the discussion has been around for more than two years.

I wasn't trying to dismiss the topic, just pointing out that I and others 
have already put forward our opinions on the issue of versioning in HTML5 
in particular. I don't want to fill people's inboxes with the same 
statements over and over again, so I figured it'd be better just to point 
to my earlier comments.


> While there are certainly problems with MIME registration, on the whole 
> MIME has been extremely successful.

In what sense? Unlabelled content is rampant, user agents (not only 
browsers) with any significant userbase uniformly treat the labelling as 
no more than a hint, some of the most commonly used types are or were 
unregistered for most of their lifetime, parameters are widely misused or 
misimplemented, and the character encoding rules are confusing, vary based 
on the transport protocol, and have caused people to use the wrong 
category on numerous occasions (e.g. XML's use of application/*).

Hardly a success story by any means, IMHO.


> The discussion in 1992 supports with your recent rediscovery that, in 
> general, versions are undesirable; however, it is also given that 
> versions are inevitable, and it is better to have explicit in-band 
> indications of intended version than it is to assume some other weakly 
> specified inference process or out-of-band communication.

I think experience with HTML, CSS, and the DOM shows that, if anything, in 
an environment with vast quantites of content and a variety of user agents 
all at different stages of implementation, it is extremely hard to have a 
versioning scheme of any kind. Even the minimal differences between quirks 
and limited quirks have had a ridiculous cost. So I disagree that 
versioning is inevitable.


> Do you have any examples of why this advice was bad for any data format 
> other than HTML, or examples of any languages or formats (other than 
> HTML) used in distributed communication where there are multiple 
> incompatible versions or modes and no explicit indication of version?

I'm not aware of a successful Web technology that is truly versioned at 
all other than HTTP, and there's very little effect even there (by 
convention only? I forget if it is actually supposed to have an effect). 
XML has versioning syntax but the one attempt to use it failed.

(Have no versions: CSS, all the DOM APIs, JS, URI, IRI, Unicode, MIME; 
have versions that have no effect: SVG, HTML, MathML, XML; have versions 
that have limited effect: HTTP. I'm not familiar enough with the GIF, PNG, 
and JPEG formats to comment on them.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 19 February 2009 07:24:39 UTC