Versioning and HTML

To kick off a broader discussion about "versioning" and web content (and HTML in particular) (W3C TAG ACTION-259):

In the 16 April 2009 HTML weekly conference call, we discussed the issues around versioning and what kinds of things the TAG could do that might be helpful to the HTML working group.

Minutes of that discussion are:
http://www.w3.org/2009/04/16-html-wg-minutes.html#item06

History:

It was suggested we look at the history of CSS and HTML evolution (I would find it interesting if the TAG looked at this from a historical perspective rather than a framework perspective. E.g. look at CSS and HTML in more detail)
For example, the issues around DOCTYPE switching:  http://hsivonen.iki.fi/doctype/
Version indicators used in HTML have included DOCTYPE, namespaces, adding new elements, attributes, new APIs, Javascript indicators of versions, MIME types, URI schemes....

Problem (from Chris Wilson):
"the general problem with how we define HTML today; if HTML5 becomes a Rec and we realize we did something poorly we will cause rampant compatibility problems if we change implementations. There are a whole bunch of versioning mechanism that will address that but also cause their own problems."

I think providing guidance and a analysis of requirements, possible solutions, and evaluation of solutions against requirements would be helpful.


Framework:

Inspired by Jonathan's posts on a framework for thinking about versioning
  http://lists.w3.org/Archives/Public/www-tag/2009Apr/0042.html

I wrote:


The general idea of 'versioning' is that you include some indicator of version in the current language that will allow current processors to deal appropriately with future languages and recognize that they don't understand or can process appropriately this future content. The main thing is to categorize or predict the kinds of future content that current implementations should avoid or react to in some appropriate way. What are those categories?

Of course, in addition, you want future processors to be able to distinguish between the future languages and the current (and legacy) languages.

I am using "version" very broadly here to indicate any evolution, extension, or variation:  as languages evolve, how do you indicate which "version" (variant, dialect, extension) language is being sent in a way that the receiver knows the sender's intention.

And I liked Jonathan's approach to the "payoff" question, but want to try to see if we could express this in terms of requirements. I.e., any version indicator solution needs to satisfy some technical and non-technical requirements: open extensibility, current and future interoperability, resilience to untrained authors using version indicators incorrectly, ability to copy/paste segments content of one "version" into another, deployment of version indicators that are outside of the control of typical authors (MIME types), ....   I'd like to elaborate the "requirements" in a document form.

I think these questions interact with "Distributed Extensibility" and "Robustness Principle" .

Larry
--
http://larry.masinter.net