CARVIEW |
Select Language
HTTP/2 200
date: Sat, 11 Oct 2025 04:01:41 GMT
content-type: text/html
content-encoding: gzip
content-location: 0183.html
vary: negotiate,Accept-Encoding
tcn: choice
last-modified: Thu, 13 Jul 2023 17:54:17 GMT
cache-control: max-age=2592000, public
expires: Mon, 10 Nov 2025 04:01:41 GMT
access-control-allow-origin: *
x-request-id: 989654c9dc63ebd9
strict-transport-security: max-age=15552015; preload
x-frame-options: deny
x-xss-protection: 1; mode=block
cf-cache-status: REVALIDATED
set-cookie: __cf_bm=6pEnC7UDQcpHbUHlDI1TXgAD9sDptjEj.xyNqg03St0-1760155301-1.0.1.1-gtwYv_kI1HlYHJ3pzsE9VI9TZ9bVKksxLjeUq3ZjaiIxuIg_cejXafsOvV1vjgjxfxQrbFyiAeXNKH7k5EmWp0k9LcVaD3lL2fJHJNjh5bo; path=/; expires=Sat, 11-Oct-25 04:31:41 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None
server: cloudflare
cf-ray: 98cb7526fe17c143-BLR
alt-svc: h3=":443"; ma=86400
Re: [errorHandling-20] CLOSED: What should specifications say about error handling? from Rob Lanphier on 2003-12-12 (www-tag@w3.org from December 2003)
Re: [errorHandling-20] CLOSED: What should specifications say about error handling?
- 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
- Message-Id: <1071209888.10731.58.camel@localhost.localdomain>
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] https://lists.w3.org/Archives/Public/www-tag/2002May/0124 > [2] https://www.w3.org/2001/tag/issues.html#errorHandling-20 > [3] https://www.w3.org/2001/tag/2003/webarch-20031128 > [4] https://www.w3.org/2001/tag/2003/webarch-20031128/#error-handling > [5] https://www.w3.org/2001/tag/2003/webarch-20031128/#ext-version
Received on Friday, 12 December 2003 01:23:47 UTC