[Prev][Next][Index][Thread]

Re: Error handling: yes, I did mean it

One of my rare postings - this is something I feel strongly about, 
for various reasons.

Yes, we do need defined error handling. I tend towards Tim's proposal 
myself, but anything reasonable would be better than nothing. The 
current HTML browser "cope with anything" is fine for HTML, and maybe 
even contributed to the Web becoming so popular, but it is not 
sufficient for the industrial strength applications that we will see 
wiht XML.

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.

But it isn't only the big browser companies who are nterested 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". 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."

The main reason why I think this is important is that applications 
will rely on having well-formed documents. To build in every possible 
error case will simply introduce bugs, increase development time, 
increase size and memory usage of applications. And then you won't 
get every memory. Authors can be extremely inventive at how they 
break documents, if they don't see any negative consequences from 
doing so. We should, as a matter of courtesy to users, allow them to 
see errors at a point before it causes damage and chaos. I wouldn't 
want my medical records to rely on HTML, nor would I want the 
aircraft maintenance manual for any plane I might be in to be broken 
- how can you trust the processing of a document that is broken? We 
could say that people should always use editors (I'd like that!) but 
it isn't going to happen. 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.

cheers,
Lauren
Follow-Ups: References: