[SpecGL] D5: Error handling

The last piece I had to produce, as far as I can tell.

David, I would like to mention something about the error handling in
XSLT 1.0, which I think you found ill-thought, due to the possibility of
having different behaviors for different errors; any pointer to a report
of interoperability issues that came out of this? or to more specific
details?

Dom

--------------------------------------------------------------------
Good practice: define an error handling mechanism

What does this mean:
For a language, address what effect an error (be it syntactic or
semantic) in the input has to a processor of this language.
For a protocol, address how should behave a party to this protocol when
a bogus message is received.

Why care?
There are many reasons a system may fail; to make a technology reliable,
it is crucial to define how it should react to bogus input.
Defining error handling also makes it possible for a user of the
technology to react appropriately to the error condition.

Techniques:
Different methodologies exist to handle errors in a technology:
- in a protocol, defining well-known error messages allows better
recovery and or reporting of these failures
- in a language, syntax errors (non-parsable content) and semantic
errors (meaningless content) can be handled separately or together; in
both cases, one should keep in mind that extensibility may need new
tokens (see WebArch document,
http://www.w3.org/TR/webarch/#extensibility), which can be smoothen by
the use of "mustIgnore" and "mustUnderstand" policies: in the first
case, a processor is required to ignore only the content that it cannot
understand, in the second one, it is required to consider as an error
that kind of content
- try and limit the number of types of error defined by the
specification; also, having errors of the same kind being processed the
same way allows greater interoperability

Examples:
- the HTML 4.01 specification doesn't define an error handling policy,
although it encourages a "mustIgnore" policy
http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#notes-invalid-docs
- the CSS specification relies on a well-defined "mustIgnore" policy
http://www.w3.org/TR/1998/REC-CSS2-19980512/syndata.html#parsing-errors
- the DOM uses well-defined exceptions and error values
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-17189187
- the XML specification is well-known for its strictness with error
conditions, where an ill-formed XML document must not be processed
http://www.w3.org/TR/2004/REC-xml-20040204/#dt-fatal
- the HTTP specification defines a set of well-known error, standardized
through their error codes
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4
- the XSLT 1.0 specification allows a processor to recover to some of
the defined errors, 
http://www.w3.org/TR/1999/REC-xslt-19991116#conformance
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org