[SpecGL Draft] D3 Good Practice: Define error handling for unknown extensions

Lynne, and WG.

D.3 Extensibility and Extensions

Good Practice
	Define error handling for unknown extensions. When defining 
extensibility, include error handling instructions for when an 
extension is not available or understood.

	Define error handling for unknown extensions

	When using a strict conforming application, users might have to deal 
with documents, data which are considered invalid because they are 
containing errors, or they are extended. Developpers will need to know 
what must be the behavior of the application in such context.

	A consistent error handling helps interoperability with regards to 
usability. There is the well known Postel law which says "Be Strict in 
what you produce, Be tolerant in what you accept". Though it has been 
shown that often this has been the start of a nightmare for 
implementers who have to deal with all the possible cases to recover 
from exotic documents (non conformant or extended). Giving a consistent 
error handling mechanism eases the work of developpers.

There are typically two approaches: (from WebArch)
	* Must ignore: ignore any content it does not recognize
	 Must ignore can be further refined, requiring that the unknown item 
be  passed through unchanged to the next downstream process, while 
other technologies simply discard it.
	* Must understand: treat unrecognized markup as an error condition.

	A good way to handle these two approaches is to have a way in the 
syntax to distinguish which behavior is expected, e.g., mustUnderstand 
attribute in Soap 1.2

Don't forget to address all your classes of products. For example, an 
authoring tool and a rendering tool might have to behave in a different 
way or not.	

Example: (todo)
	* SOAP 1.2
	* XML: Well-formed or invalid...
	* XHTML 1.0
	* HTML 4.01
	* Ruby?

Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Received on Wednesday, 23 June 2004 19:16:11 UTC