Versioning and HTML -- recap

I think the discussion on versioning and HTML got unnecessarily diverted into the wishful thinking that somehow perfection would be achieved through the CR process.

To recap where we actually are on ACTION-259 and discussion of versioning for HTML:


 *   Review history of previous work: http://lists.w3.org/Archives/Public/www-tag/2009Apr/0028.html , and update ISSUE-41 http://lists.w3.org/Archives/Public/www-tag/2009Apr/0061.html
 *   Analyze the kinds of language changes that have occurred in the past and might occur in the future, so we can correlate them to the utility of version indicators (not really started)
 *   Describe reasons for language changes of various sorts (started http://lists.w3.org/Archives/Public/www-tag/2009Apr/0063.html )
 *   Enumerate the kinds of version indicators available generally (out of band, in-band global, in-band local) and specifically for HTML  (MIME types, comments, DOCTYPE, new tags, namespaces), (started in http://lists.w3.org/Archives/Public/www-tag/2009Apr/0075.html )
 *   Look at past behavior and predict future behavior for browsers and others introducing language changes, to understand how different behavior has different payoff (started in http://lists.w3.org/Archives/Public/www-tag/2009Apr/0065.html )
 *   Review the compatibility and development workflow strategies for using different kinds of version indicators (future content with current readers,  distinguishing current from future content with future readers) http://lists.w3.org/Archives/Public/www-tag/2009Apr/0064.html
 *   Evaluation criteria: evaluate the use of version indicators against possible future language changes to determine what are the reasons for and against using version indictors (to be done)


I'm thinking the above might serve as the initial content and outline of a finding around versioning and HTML.

Of course, any decision to require or encourage use of version indicators as a way of modulating behavior will require some agreement of current browsers to do work that will only pay off in the future, and getting that agreement requires buy-in by the affected parties. However, I don't want to start with the presumption that "they won't go along" without first making the case for why allowing for future non-compatible extensions in current browsers is good practice, even when such changes should be avoided if at all possible.

Larry