Re: draft on versioning and HTML

> http://larry.masinter.net/versioning-html.html

I think there are three major points that the draft fails to address:

  1) The draft seems to assume that incompatible changes between spec  
text in spec version N and spec version N+1 are what matter. This  
isn't so. What matters are incompatibilities with existing content and  
prospective implementations. If spec version N says something that's  
incompatible with existing content if implemented, it's quite OK for  
spec version N+1 to adopt a stance that contradicts spec version N but  
is compatible with existing content. Such a change doesn't cause any  
real problem. In fact, pretending that implementations of spec version  
N+1 had to alter their behavior for content labeled as being written  
to spec version N would lead to unhelpful complexity.

Specifically, the formalism in Appendix III needs to be considered in  
the context of what is deployed--not in the context of what is  
specified. Basically, when writing spec version N+1, the spec writers  
should assume that spec version N may be nonsense and instead go see  
what actually got deployed.

  2) The draft seems to assume that if there's a language spec for  
version N, implementations implement it fully, and when spec version N
+1 comes along, implementations move to implementing N+1 fully. This  
is not the case on the Web. User Agents implement specs piecemeal and  
may ship a partial implementation of spec version N+1 before having  
completed all features of spec version N.

Since the actual compatibility issue is between existing content and  
implementations and not between spec revisions, trying to base version  
indicator-based behavior alteration on spec versions is a futile  
exercise. Trying to base version-based behavior alteration on  
implementation versions is a harmful exercise: see http://dev.opera.com/articles/view/opera-ua-string-changes/ 
  and http://ln.hixie.ch/?start=1201080691&count=1 for different  
aspects of trying to do version with implementations version indicators.

  3) The draft seems to assume that it's sometimes OK to make changes  
that would cause so much incompatibility without a version indicator-
based behavior change that a version indicator-based behavior change  
in implementations is needed. I think assuming this is the source of  
most problems in versioning discussions. It is *not* OK to make such  
changes even if it means that the language remains inelegant on a  
given point to eternity. Future revisions of the language spec and its  
implementations have to be constrained to making only changes that  
don't break a substantial part of existing content. When you feel you  
need a version indicator-based behavioral switch, you are probably  
about to break a substantial part of existing content. If you feel you  
can ship the change in a mainstream browser without a version  
indicator-based behavioral switch, you probably aren't breaking too  
much of existing content and the change may be justified. The whole  
quirks vs. standards mode switch shouldn't be seen as a precedent to  
replicate but as a learning experience of something that should never  
be repeated.

P.S. Algol is not really relevant, because people who operated Algol  
compilers had the power to tweak the programs. The Web is a completely  
different environment, because users of browsers can't practically  
tweak the input the browser gets from a site.
--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/