- From: Lauren Wood <lauren@sqwest.bc.ca>
- Date: Sun, 20 Apr 1997 21:18:39 -0800
- To: w3c-sgml-wg@w3.org
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
Received on Monday, 21 April 1997 00:19:04 UTC