Re: Sudden death: request for missing input

At 07:10 PM 28/04/97 CDT, Michael Sperberg-McQueen wrote:
>I think requiring that a processor die when confronted with
><foo bar=baz>...</foo> or with <a><b><c> ... </a>, instead of
>allowing the user and the application together to decide whether
>these might be typos for <foo bar='baz'> and <a><b><c> ...
></c></b></a> seems a more moralistic attitude than is strictly

Neither <foo bar=baz> or <a><b></a> are XML; XML is simple enough that 
there is a good probability that these, rather than author error, are the 
result of a broken communication link or output filter.  The proper
response to such breakage is prompt termination without extreme prejudice 
but with a clear error signal.

I do not want us lurching over the slippery slope where every little 
formerly-lightweight piece of useful XML client code is loaded with 
bloated guess-what-the-author-really-meant heuristics.  Empirical
evidence would suggest that the danger of this is real.

Someone a few messages back proposed a policy where a browser
has to maintain a continuous this-document-is-dogshit display 
in the presence of non-well-formed instance.  I can't at the
moment see how to engineer the spec to achieve such a constraint;
if we could, I suppose this would be tolerable.  At a *very bare
minimum*, we must remove the phrase "at user option" from the 
definition of "reportable error" in section 1.3.  I can see no
scenario in which it is ever desirable to suppress a 
well-formedness error message.

We went to a lot of work to make well-formedness easy.  It is a very 
low bar to get over... much easier than producing valid HTML.  I 
cannot for the life of me see why so many people here are willing to 
tolerate gross error, and run the risk of another race-to-the-bottom a 
la HTML, when the standard required to achieve reliable interoperability 
is so easy to explain and to achieve.

Cheers, Tim Bray +1-604-708-9592

Received on Wednesday, 30 April 1997 01:46:50 UTC