Re: Counter change-proposal for ISSUE-4 (html-versioning)

Thanks for the submission. I recorded this counter-proposal on the  
issue status list:
http://dev.w3.org/html5/status/issue-status.html#ISSUE-004


On Feb 21, 2010, at 10:08 AM, Adam Barth wrote:

> According to http://dev.w3.org/html5/status/issue-status.html, the
> deadline has passed for Larry's initial change proposal for ISSUE-4.
> The change proposal linked from that page is
> http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html.
> Here's my counter proposal:
>
> = Change Proposal for ISSUE-4: No DOCTYPE Versioning =
>
> == Summary ==
>
> The DOCTYPE should not contain a version indicator.
>
> == Rationale ==
>
> Historically, user agent implementors have invested a great deal of
> effort to construct user agents that can process legacy HTML documents
> properly. In particular, HTML5 contains algorithms painstakingly
> researched to be compatible with exiting web documents. Current trends
> indicate that future evolutions of the HTML language will continue to
> be backwards compatible with the large number of existing HTML
> document on the Web. For this reason, a version indicator is not
> necessary at this time for HTML.
>
> Worse, a version indicator is actively harmful. Even though previous
> versions of HTML have contained version indicators in the doctype,
> these version indicators often bear little or no relation to the HTML
> contained in the document. Authors simply copy-and-paste seemingly
> meaningless boilerplate from one document to another. These version
> indicators are simply ignored by user agents because processing the
> version indicator has negative benefit to users.
>
> The doctype is used for one version-like purpose: selecting between
> "quirks mode" and "standards mode" (well, and "almost standards
> mode"). Supporting these different rendering modes in user agents adds
> complexity, harming interoperability between user agents and making it
> more difficult to author documents. The introduction of
> X-UA-Compatible, a versioning-like mechanism, has received almost
> universal distain from authors and made it nearly impossible to
> predict how an HTML document will be rendered in a supporting user
> agent. Adding hooks for more versioning serves only to facture the web
> platform and retard the growth of the Web.
>
> The remainder of this section presents a point-by-point response to an
> alternative change proposal for this issue:
> http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html
>
> 1) Historical perspective on the doctype is laudable but independent
> of whether HTML5 provides for a version indicator in the doctype.
> 2) HTML5 alters the conformance status of a great many sequences of
> bytes that might be presented with the text/html media type. It is
> unclear why the conformance status of the doctype is of specific
> concern.
> 3) I agree that determining whether or not the doctype provides for
> versioning is in scope for the working group.
> 4) Supporting polyglot documents is independent of supporting
> versioning. For example, the about:legacy-compat mechanism supports
> XSLT generation of HTML documents without introducing a versioning
> mechanism.
> 5) I agree that other proposals for versioning HTML are also  
> undesirable.
> 6) The rationale contained herein makes no reference to reverse
> engineering costs.
> 7) The doctype declaration /is/ mostly useless. Its sole use is to
> select between quirks mode and standards mode, which is actively
> harmful to authors of new HTML documents.
> 8) The rationale contained herein makes no reference to version of
> implementation.
> 9) I agree that version-specific behavior by user agents is  
> undesirable.
> 10) The syntax of the version indicator is not at issue in this  
> change proposal.
> 11) Please see the detailed discussion below of the opportunity cost
> of not including a version indicator.
> 12) The syntax of the version indicator is not at issue in this  
> change proposal.
>
> == Opportunity Cost ==
>
> This section is adapted from
> http://lists.w3.org/Archives/Public/public-html/2010Jan/0295.html.
>
> The primary remaining rationale for having a version indicator is that
> we might find such a version indicator useful in the future (even
> though we agree that this eventuality is unlikely). Larry has written
> that the opportunity cost of not making this change is merely a time
> delay (i.e., between steps 1 and 2 described in
> http://lists.w3.org/Archives/Public/public-html/2010Jan/0232.html) in
> the hypothetical future in which we need to make an incompatible
> change to HTML. Let's do a back of the envelope cost/benefit analysis
> of this opportunity cost.
>
> First, we need to estimate various input quantities:
>
> 1) Probability that we'll make an incompatible change to HTML in the
> future that necessitates these version markers. Larry and I agree that
> this is unlikely. Let's say the probability is 1%. (I actually think
> it's much lower, but a reasonable person might think that it's
> higher.)
>
> 2) At what time in the future will this change be needed? Let's say 15
> years. Ian estimates that HTML5 will be a proposed recommendation in
> 2022, so that gives us a couple years of headroom to realize that we
> screwed up without being able to change the spec.
>
> 3) Delay between steps 1 and 2 caused by not changing the spec in this
> way. Let's say it takes 5 years for people to update their validators
> to understand that version indicators are ok. This seems ample to me.
> (Notice that if people could update their validators instantly, there
> would be no delay between steps 1 and 2 and the change to the spec
> would have zero value.)
>
> 4) Long term, risk-free rate of return. We need this quantity to
> estimate the time-value of various things. Five year treasuries are
> trading at 2.62% when I wrote this analysis, but that's probably on
> the lower side of historical averages. Let's say 5% as a more normal
> discount factor.
>
> Ok, now we're ready do to do the calculation. Suppose the benefit is
> $1,000,000. Deflating by the total probability of this eventuality
> gives us $10,000. Now, we're only extracting the time value of this
> benefit since we get the benefit, just five years later. That gives us
> the utility lost due to delay of roughly $2126 = $10,000 - $10,000 /
> (1.05)^5 (see http://en.wikipedia.org/wiki/Present_Value for an
> explanation of this equation). Now, we need the present value of that
> quantity, which is roughly $1027 = $2126 / (1.05)^15.
>
> In summary, for every million dollars of benefit we would get from
> having this versioning feature, we only lose $1000 of utility today by
> not making the change to the spec. That means the benefit of making
> this change must be 1000x greater than the cost to have a positive
> payoff.
>
> == Proposal Details ==
>
> The proposal details herein take the form of a set of edit
> instructions, specific enough that they can be applied without
> ambiguity.
>
> * Perform no edits.
>
> == Impact ==
>
> * Adopting this change proposal will have neither positive nor
> negative effects because it does not propose modifying the current
> specification.
> * No conformance classes will change as a result of adopting this
> change proposal.
> * See the Opportunity Cost section of this change proposal for an
> analysis of the risks involved in adopting this change proposal.
>

Received on Wednesday, 24 February 2010 03:06:04 UTC