Working Group Decision on ISSUE-4 (html-versioning) and ISSUE-84 (legacy-doctypes)

The decision follows.  The chairs made an effort to explicitly address all
arguments presented in the Change Proposals on this topic in addition to
arguments posted as objections in the poll.


      *** Question before the Working Group ***

The HTML5 Doctype does not contain an explicit version indicator, and provides
an alternative intended to simultaneously support yet discourage legacy
toolchains.  Some members of the working group have suggested that a version
indicator is needed, others questioned whether the legacy DOCTYPE should be
discouraged.  The result was two issues, two change proposals and a straw poll
for objections:

http://www.w3.org/html/wg/tracker/issues/4
http://www.w3.org/html/wg/tracker/issues/84
http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html
http://lists.w3.org/Archives/Public/public-html/2010Feb/0718.html
http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/results

*== Uncontested observations:*

Reading through the arguments, a number of proponents for various proposals
did so after stating a number of concessions:

* The DOCTYPE has been part of HTML, and is required
* The DOCTYPE is of limited utility
* If needed, versioning is in scope
* Polyglot documents are supported
* Version specific behavior by user agents is undesirable
* Backwards compatibility is central to HTML

None of these were decisive.  There were people who supported either of
these proposals even after taking these facts into consideration.  The fact
that they were acknowledged up front was appreciated.

*== When to add a version indicator to a language*

This seems to be the core point of contention, and appears in point 11 in the
original change proposal.  The key assertions to be evaluated:

* Not including a versioning identify now incurs opportunity costs
* Versioning, if needed, can be added later

A list of languages and protocols were presented by both sides as supporting
evidence.  It was noted that HTTP 0.9 did not have a version indicator, and
that one was added in HTTP 1.0.  See "Arguments not considered" for JavaScript
considerations.

An assertion was made in one change proposal that if a version indicator were
ever to become necessary that it would be important to provide an explicit
means to opt out at the same time.  While this assertion was made, no evidence
was given to back it up.  As previously noted, HTTP provided an effective
counter example.

There also did not appear to be any dispute that if the current HTML5 DOCTYPE
were adopted and if there were incompatible changes needed in the future, and
if the DOCTYPE were the place to add it, that it could be done.

Thus the case was not made for introducing a versioning mechanism.  This, in
turn, was the basis for a number of objections which were found to be strong:
burdening the language with syntax for something that will likely never exist;
allowing something that has no observable effect leads to confusion; and the
indicator itself would tend to encourage fragmentation and additional modes --
something that there is general consensus is undesirable.

*== Other arguments*

* Redefining a MIME type vs previously conforming documents

It was pointed out that this change, in isolation, does not comprehensively
address this problem: HTML5 alters the conformance status of a great many
sequences of bytes that might be presented with the text/html media type.
As such, this part of the proposal attracted unrebutted objections based on
relevance.

* "Mostly useless" is "childish" or "petulant"

Only anecdotal data was presented to support this assertion.  While there was
some discussion as to what the differences between this phrase and "of limited
utility" mean, no assertion could be found that "of limited utility" was more
accurate.  By contrast there were a number of uncontested assertions to the
contrary.


        *** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the Change Proposal to
not put a versioning indicator into the DOCTYPE.  Of the Change Proposals
before us, this one has drawn the weaker objections.

*== Next Steps ==*

Bug 7727 is to be closed and marked as WGDecision.  Issues 4 and 84 are also
to be closed.

Since the prevailing Change Proposal does not call for a spec change, no
further actions are required.

*== Appealing this Decision ==*

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.

*== Revisiting this Issue ==*

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Identifying a specific backwards incompatible change that requires a
   versioning indicator
*
== Arguments not considered ==*

* Other versioning ideas
=>  only proposals that were put forward were considered

* Reverse engineering costs
=>  only proposals that were put forward were considered

* Version of implementation ideas
=>  only proposals that were put forward were considered.  There was an
argument that even if it wasn't explicitly intended by either proposal, it
could be the result.  While the strength of this objection wasn't evaluated,
it could only have made the case strong for the decision that was ultimately
made.

* URNs as PublicIdentifiers
=>  only proposals that were put forward were considered

* DTDs should not be supported because they are inferior
=>  Possibly true, but not substantiated

* Allowing DOCTYPE to have an observable effect leads to a maintenance burden
=>  Neither proposal included any HTML interpreter changes

* DOCTYPEs have some value in evaluating historical documents
=>  While the wording differed ("mostly useless" vs "limited utility"), both
of the proposals presented essentially agreed on this basic point.

* Priority of web use cases over controlled environments
=>  Once the uncontested and not-considered arguments were eliminated, this
no longer was relevant

* Inclusion of "EN" in the version identifier
=>  Did not appear to be an objection to what is in the current draft, and
presupposes that a version identifier is necessary

* JavaScript has never used explicit versioning
=>  ES5 introduces behavior changes with an explicit opt-in via "use strict".
Could support the need for versioning; could also support the idea that the
addition of a versioning indicator can be deferred; could argue that an
explicit opt-out is not needed; in any case, arguments weren't presented
and therefore not considered.

* Adding in a version indicator adds opportunity costs
=>  Unclear that this meets the bar as a "strong objection", but in any case
there was no need to evaluate the strength of this argument as there were
ample other arguments which were found to be strong.

* Editing environments may benefit from from versioning indicators
=>  It is not clear whether this argument was actually made, the closest that
was made is a comment that one possible choice (that nobody has advocated)
"doesn't seem to improve anything", and there was as an argument AGAINST
PublicIdentifiers being used in some XML-based workflows.  In any case, the
argument (if it was made at all) wasn't supported and did attract uncontested
objections.