W3C home > Mailing lists > Public > www-tag@w3.org > May 2002

New issue: error recovery practices (Re: Proposed TAG Finding: Internet Media Type registration, consistency of use)

From: Rob Lanphier <robla@real.com>
Date: Wed, 22 May 2002 15:02:58 -0700 (Pacific Daylight Time)
To: Tantek Çelik <tantek@cs.stanford.edu>
cc: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <Pine.WNT.4.43.0205221427050.313-100000@robla350.dev.prognet.com>
Summary:  this is a request that the TAG issue a finding regarding
appropriate error resilience/recovery/"second guessing" in web software.

As Tantek points out, the current finding on Internet Media Type
registration (http://www.w3.org/2001/tag/2002/0129-mime) contains the
following language:

   "Web software SHOULD NOT attempt to recover from [incorrect media
type labeling] by guessing, but SHOULD report the error to the user to
allow intelligent corrective action."

This seems to be an instance of a general architectural principle that
guides the current direction of W3C Recommendations.  I'd like to request
that the TAG come up with generalized guidance on the appropriateness of
error recovery in web software.  Specific manifestations of this issue:

*  How should incorrect media type labeling be handled? (the answer is
*  Should future XML-based language specifications from W3C extend
   traditional XML strictness into attribute values and other areas left
   undefined by XML?
*  Should specifications be clear on what is safe to ignore?  (I would
   hope so....not always the case, so perhaps this should be written down)
*  When is it safe to specify that unknown issues can be ignored
   ("ignorability"), and when must specification writers not allow

There is a related class of issues under discussion in the QA working
group that may or may not fold into this one.  They are discussing
conformance requirements for backwards-compatibility and deprecated
features.  See http://www.w3.org/QA/WG/qawg-issues-html.html#x51 for more

Received on Wednesday, 22 May 2002 18:01:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:51 UTC