Re: [arch-d] deprecating Postel's principle- considered harmful

["Henry S. Thompson" <[e-mail]>]

Paul Wouters writes:

> ...
> The problem is not the Postel principle. The problem is that we have "too
> big to fail" implementations

A historical example may illustrate how high the (organisational) stakes
can be.

The W3C lost control of HTML as a result of a decision, late in the last
century, to commit to XML as the basis for the successor of HTML4 (for
the W3C's own account of this, see [1]).

The 'too big to fail' implementations in this case were initially those
of Apple, Mozilla, and Opera, with Google joining in a bit later.
Different aspects of XHTML2 (the proposed XML-based successor to HTML
4.01 and XHTML1.0) were problems for different constituencies and to
different degrees, but what its opponents regularly cited as XML's
insistence on a "halt and catch fire" approach to ill-formed documents
was the one that was argued with perhaps the most bitterness.

Postel's 'law' was regularly invoked in arguments against the XML
approach, and it lives on in the current version of what is now called
the "Living Standard" of HTML5, as published by the W3C, where we find,
_inter alia_, in the section entitled *Conformance requirements for
authors":

  "Unlike previous versions of the HTML specification, this
   specification defines in some detail the required processing for
   invalid documents as well as valid documents." [2]

One way of understanding the dynamic behind the transfer of effective
ownership of HTML from the W3C to the WHATWG (a quasi-consortium of
Apple, Mozilla, Opera and Google) is as a replay of (the mythology of)
the foundation of the W3C itself, namely, that back in 1988 Microsoft
and Netscape needed a way of managing HTML development that didn't
violate the anti-trust rules.  In the early part of this century, a
major part of browser interop problems lay in the area of error
recovery.  The W3C's XML-based approach was intended to solve this by
"cleaning up the Web":  XHTML2, by being XML, would require strict
enforcement of well-formedness and encourage strict enforcement of
validity.

The browser vendors, in contrast, were terrified of the cost of
increased support calls they predicted would arise, and preferred a
solution sometimes described using the phrase "paving the cow paths",
that is, standardising error recovery.  [see below at **]

The result is a 1069-page-long standard with no BNF or any other form of
concise grammar.  There are 11 pages of prose describing the low-level
'syntax' (angle-brackets and equal signs), and 100 pages of prose
describing the generic parsing _process_, including, of course, error
recovery. And there are just under 500 pages of prose describing, for
every allowed element, how to process its serialisation in detail,
including error recovery.

Would we have been better off with XHTML2?  Not in the short term, I
don't think.  But by now?  How can we know?  But, as Berners-Lee is fond
of saying, "The future is longer than the past"...  We will keep paying
the cost of the lack of incentives to clean up the Web for a long time...

ht

[1] https://www.w3.org/TR/html5/introduction.html#introduction-history
[2] https://www.w3.org/TR/html5/introduction.html#conformance-requirements-for-authors

** John Klensin's recent post arrived after I had written this.  I think
his description of "the first option" is perfectly borne out by what
I've described above:

> -- trying to specify every possible detail so that an
> implementer knows what to do in every case and for every design
> choice, including what is supposed to be done about each variety
> of deviation from the standard by others.

> ...

> We know a few things about [this option].  It causes the standards
> development process to take much longer than [the alternative].
> Because standards designers are not infallible, it is prone to errors,
> errors that could make the standard completely unworkable.  For [HTML,
> it was only possible because] there are complete and deployed
> implementations around that [could] be examined and analyzed ... in
> combination, in [building] the standards.
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: [e-mail]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.