- From: Karl Dubost <karl+w3c@la-grange.net>
- Date: Wed, 17 Jun 2009 10:40:20 -0400
- To: Michael(tm) Smith <mike@w3.org>
- Cc: Shane McCarron <shane@aptest.com>, public-html@w3.org
Le 17 juin 2009 à 07:03, Michael(tm) Smith a écrit :
> So I guess I'm not convinced that other standards for handling
> Internet content shouldn't also be specced out with a degree of
> rigor and thoroughness in defining (and iteratively updating
> during further development and testing) rules for error-handling
> similar to what we have ended up with in the current HTML5 draft
> (and other drafts we have now that are related or spun-off from it).
On Mon, 19 Mar 2001 10:41:51 GMT
In The experience of the Batik team in implementing W3C's
specifications
At http://www.w3.org/2001/01/qa-ws/pp/thierry-kormann-ilog.htm
'implementation dependant' or unspecified
behaviors are really dangerous as far as
interoperability is concerned. When a working
group does not find a solution and plan to let a
particular behavior or feature unspecified or
dependant of the implementation, perhaps the
following question will help:
Considering now that two implementations are doing
different things, is it important for users or
not?
May be, the answer is 'no' and the feature can be
kept as is. Otherwise, the working group can
decide to specify the behavior even though a vote
is required. The answer could also be: "It is an
error" and what error is it, could just be a
highlevel description such as the one in the SVG
specification. In any case, it will be one of the
QA activity's biggest challenge.
See also
* Define Error Handling mechanism
http://www.w3.org/TR/qaframe-spec/#error
* Discretionary Items
http://www.w3.org/TR/spec-variability/#optionality
--
Karl Dubost
Montréal, QC, Canada
http://twitter.com/karlpro
Received on Wednesday, 17 June 2009 14:40:28 UTC