Re: Versioning re-visited (was : mixed signals on "Writing HTML documents", tutorial, etc.)

On Fri, 22 Jun 2007, Alexandre Alapetite wrote:
> Anyway, since we are there, I have problems with your argumentation
> since you do not really explain why we should /not/ have versioning,
> but instead you try to show that versioning is sometimes superfluous.

I detailed the reasons for not having versioning in a previous mail, to 
which I linked:

...which itself links to three more e-mails giving arguments against 
versioning. The purpose of my last e-mail was not to give arguments 
against versioning, since those have been discussed in detail already, but 
to show that the arguments _for_ versioning were weak or wrong.

> > > * An explicit version helps a browser or any reader to know the 
> > > intention of the author.
> > 
> > This only works if the author actually knows what his intent is. 50% 
> > of pages on the Web have no DOCTYPE [1]. So it's not clear to me that 
> > you can actually determine the intention of the author from the 
> > version.
> Your reasoning is strange to me: if the author of a Web page did not 
> chose to include an explicit version, then there is none... Furthermore, 
> from your own statistics, 50% of the Web pages /do/ have versioning. It 
> would also be interesting to know how this proportion evolves over time, 
> with the CMS, editors and Web masters becoming better. For all those 
> people who /chose/ to have explicit versioning, your argument does not 
> seem to be valid.

More data would indeed be useful; however, my point was that authors 
rarely know what their intent is, and that versioning information in a 
document is therefore a poor guide as to their intent.

> > Furthermore, if you keep your language backwards-compatible, the 
> > intent of the author is independent of which version was current when 
> > the document was written. So versioning isn't the only way to catch 
> > author intent.
> That is not a point against versioning. You just say that /maybe/ 
> versioning is superfluous in some cases.

Right. I'm pointing out that this argument for versioning is weak, as 
there are better ways to solve the purported problem.

> > > * Versioning is needed to update the HTML recommendation without 
> > > breaking existing content.
> > 
> > This is clearly untrue, since the version has never been used for this 
> > purpose despite HTML being on its 9th revision (HTML1, HTML+, HTML2, 
> > HTML3.2, HTML4, HTML4.01, XHTML1, XHTML 1.1, HTML5/XHTML5). (Some of 
> > those revisions did have version information -- though not all -- but 
> > in no case was the version identifier used to avoid breaking content.)
> There are differences between all those version, both in the syntax, 
> grammar and semantics.

Indeed, but in none of the above cases has versioning been used to allow 
recommendations to be updated without breaking existing content. User 
agents have not looked at the versioning information to infer the version 
of the document and act appropriately at any point in HTML's deployment.

> > > * It allows the automatic validation of the HTML documents against 
> > > the precise HTML version they are targeting.
> > 
> > This is still possible without version information, you just need to 
> > tell the conformance checker what you intend to test against. CSS 
> > works like this, for instance.
> By definition, "automatic" means that there is no such a "you just need 
> to tell"... So the point for versioning is still valid. While it is true 
> that it is possible to pick up by hand the version to use (if the author 
> has a way to remember which version was used for one given document), it 
> is harder when you face thousands of documents from various generations.

I agree that it is not possible to automatically select the version that 
was contemporary when the document was written. However, I contend that 
that is not a desirable feature, and may in fact be undesirable as it 
results in outdated conformance reports with false-negatives and false- 
positives. See the earlier cited e-mail.

> > > * Allows "flavours" of HTML such as "XHTML Basic".
> > 
> > Profiling the data-level language is harmful, but even if it wasn't, 
> > versioning isn't actually required to do it. CSS, for example, is not 
> > versioned but has been successfully profiled many more times than 
> > HTML.
> Well, I do not know if CSS is a good example, but I personally do miss a 
> version and profile, for instance to do automatic validation.

My point here was related to the purported advantage of versioning. I'm 
merely pointing out that this purported advantage is not actually related 
to versioning and shouldn't be used to support explicit versioning. 
Versioning doesn't enable profiling. They are orthogonal.

> > > * A validator may advise updating to a newer version if it can 
> > > automatically tell what version was used, and another tool may 
> > > provide some help in the conversion to the newer version.
> > 
> > If you omit versioning information and ensure the language remains 
> > backwards compatible, there is actually no need to update anything.
> Here again, you say that /if/ we are lucky and things stay as you want 
> them to be, versioning may be superfluous. No point against it there.

We're talking about versioning in HTML5. We have control over HTML5. 
Modulo the argument below (that adding versioning to a future version when 
HTML5 doesn't have it would be aesthetically displeasing), I don't see 
that not having versioning at this point would stop a future version from 
readding versioning and re-enabling these notifications if backwards 
compatibility was to be sacrificed at some future point.

> > > * A special extra knowledge will be needed to know that <!DOCTYPE 
> > > html> means HTML 5 (or any later version until a version mechanism 
> > > is re-introduced).
> > 
> > It doesn't mean "HTML5", it means "HTML".
> Well, this depends on the view point. Since HTML 4 is not valid HTML5, 
> you may have to tell the authors of all those HTML 4 pages that they are 
> not doing HTML pages after all.

HTML4 is also HTML. I don't understand what you mean. My point was that 
the proposed HTML5 DOCTYPE, without versioning information, merely 
indicates that the document is an HTML document, not that it is an HTML5 
document (or any other version, for that matter).

> > > * There will be no consistency with previous HTML versions if we use 
> > > <!DOCTYPE html> for HTML 5 and need to reintroduce the public 
> > > identifier in later versions.
> > 
> > True. Of the ones you listed, this seems to be the only valid reason 
> > to have versioning.
> Good, at least we agree on one point.


> > So in conclusion, as I see it the arguments in favour of versioning 
> > boil down to aesthetics, and the arguments against include dire things 
> > like us losing competitiveness in the browser space. [2] [2] 
> >
> Actually, regarding "competitiveness in the browser space", I would like 
> to point you again to the arguments from the Internet Explorer team:

Given that the danger of versioning resulting in anti-competitive 
behaviour was first brought up specifically because the IE team was 
suggesting implementing a versioning feature that would have long-term 
anti-competitive effects on the browser market, and that Microsoft is a 
convicted monopoly-abuser in several jurisdictions and therefore has a 
track record of taking advantage of features that can be leveraged against 
healthy competition, I am not sure that appealing to Microsoft's position 
is an effective counter-argument here.

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

Received on Friday, 22 June 2007 12:38:54 UTC