Re: Error handling: yes, I did mean it

Here's a compromise: if you and Tim are so convinced that browser
vendors really want to do this, why don't we put it in the spec as a
non-binding recommendation? You'll be doing the "reccommended" thing,
but your hands will not be tied if my prediction is correct and the arms
war resumes. If Netscape and Microsoft are really interested in a truce,
they will have our encouragement and blessing in achieving it.

Lauren Wood wrote:
> One question raised was whether MS and NS will support this - the
> answer as far as I can tell is yes. People from MS have stood up in
> public and said how they regret some of the HTML error acceptance.
> They have learnt from experience.It is reasonable to assume that
> people in NS feel the same way. XML gives a fresh start for people
> who care about the data, and care whether it is correct and can be
> processed.

I believe that Microsoft and Netscape regret the HTML error handling
mess just as Ronald Reagan regrets the arms race. It is expensive and
dangerous, but in the same situation the same people would make the same
decisions (well, maybe the communists would try another approach). As
soon as one side fails to implement some check or the other, web pages
will start to expect that and the other tool will be labelled "overly
strict" if it doesn't at least try to render the document (perhaps with
an error message!). I can understand why SoftQuad in particular is
concerned about this issue, because HoTMetaL has had to bend over
backward to work with the HTML mess, but we in Canada also regret the
arms race, and I don't think that this working group will have any more
success legislating the display of bad documents out of existence then
the UN would ICBMs.

But when did these companies begin to care about implementing a standard
to the letter of the law? How many valid HTMLisms do they choke on? That
can't be blamed on history: they always have the option of allowing new
constructs, but there are many valid HTML documents that they cannot
work with, or interpret incorrectly. The fact is that in this day and
age, "implementing" a standard means implementing the broad strokes. The
little technicalities are typically ignored. This is just such a small
technicality, and it is exactly the sort that they are likely to ignore,
especially since Netscape is already lukewarm to XML.
> But it isn't only the big browser companies who are interested in
> this. I work for a company that makes an HTML editor based on an
> SGML editor, and our most common user complaint is that we don't
> treat documents the way a browser does. People use browsers to
> "validate" their documents. If there is an agreed-upon behaviour,
> then each company (including the big ones) will be able to point at a
> specification which details agreed-upon behaviour, and say "we are
> doing what we should be doing". 

You can do that now, Lauren. But who would care? Would a single customer
reccommend HoTMetaL to his or her friends: "It chokes on a lot of
documents that are fine in browsers, but I called tech support and they
told me that the specification says that they are okay." Even if you
could convince 1 in 100 users that the XML spec is relevant, 99 don't
call. As far as the users are concerned, the browsers are the
specification. This is an unfortunate market reality that we can't
legislate out of existence.

> Smaller vendor companies like
> SoftQuad will be able to do the same. Requiring consistent error
> handling is a way to let *everyone* get off the treadmill of having
> customers say "competitor X copes with my pages; why don't you."

Not at all. People have always and will always expect bug for bug
compatibility. The spec is really irrelevant in this regard (convincing
end users of who is right). Spec documents are for language lawyers and
vendors, not end users. All this requirement will do is tie your hands,
as a conscientious vendor, in competition with dozens of "Hotdog" style
editors who will be glad to load and edit any crap. The more
conscientious of them may even pipe their input to sgmls, report the
errors and load the document, but you'll be stuck with the same error
messages but half a document.
>People will use whatever application they
> have handy as a validator - it would be much better if different
> applications gave much the same error results for invalid documents.

Requiring an error message, and even requiring the exact text of the
error message, is different from saying what the system can do when the
error has been reported. Once the error has been reported the rest
should be up to the application.

 Paul Prescod

Follow-Ups: References: