- From: Rob Lanphier <robla@real.com>
- Date: Thu, 11 Dec 2003 22:18:08 -0800
- To: Chris Lilley <chris@w3.org>
- Cc: www-tag@w3.org
Hi Chris, Sorry for the delayed response on this issue. I agree that errorHandling-20 is handled acceptably and can be closed. Thank you to you and the rest of the team for tackling this issue. I have issue with the backwards compatibility issue, but that is a separate issue that I will reply to under separate cover. Rob On Tue, 2003-12-02 at 10:45, Chris Lilley wrote: > Hello Rob, > > At our Yokohama f2f meeting, the TAG noticed that many aspects of the > issue you raised [1] and which we accepted as issue 20 [2] > > errorHandling-20: What should specifications say about error handling? > > are by now addressed in the current Architecture Document [3]. > > Specifically, section 1.2.3 [4] discusses error handling, requires > specification of error handling, and establishes that silent recovery > from errors is harmful, thus addressing your 'second guessing' point. > > Section 4.2 [5] discusses extensibility and versioning, what > specifications should say about when to ignore extensions and when > extensions must be understood. > > You also raised the issue of conformance to deprecated features, and > suggested it might be a different issue. It seems that a deprecated > feature is one that content authors and authoring tools should not > produce, and that content consumers must understand. > > We propose therefore to close issue 20 as already addressed. Please > let us know whether you are satisfied with this outcome. Thanks again > for your help and contributions, > > > [1] http://lists.w3.org/Archives/Public/www-tag/2002May/0124 > [2] http://www.w3.org/2001/tag/issues.html#errorHandling-20 > [3] http://www.w3.org/2001/tag/2003/webarch-20031128 > [4] http://www.w3.org/2001/tag/2003/webarch-20031128/#error-handling > [5] http://www.w3.org/2001/tag/2003/webarch-20031128/#ext-version
Received on Friday, 12 December 2003 01:23:47 UTC