Re: [SpecGL Draft] D5 Error Handling

An additional item is error handling resulting from a deprecated feature - 
ifor example, issue an error f a deprecated feature is used when it is 
strictly forbidden (e.g., disallow it in a producer, although allowed by 

This may be a good topic to start on the IG list.  I'm also wondering if 
there is a way to handle this section generically and include lots of 
examples - like those you have below.  So for a generic principle something 
like: address the need specifying error handling.  Meaning, that there are 
some situations, e.g., extensions, not authorized syntax, redefining 
another technology's default, when the specification needs to describe the 
action to occur.


At 04:07 PM 6/30/2004, Karl Dubost wrote:
>For the WG
>D5. Error Handling?
>@@ should we address this? does it belong here?
>There's a section right now which is called Error Handling but which is 
>not filled. I think it has to be clearly defined because it's part of the 
>quality of a technology, though I would like to clear a bit the bush 
>before. I guess it would benefit from a wiki topic if not done yet.
>This is what I have identified as possible places where technologies might 
>need "Error Handling".
>* Not authorized Syntax
>         * Invalid syntax, when a document, for example XHTML, SOAP 
> Envelop, etc. Do not respect a DTD or an XML Schema. Though some 
> specifications doesn't have a DTD or schema language. For example
>         - XSLT
>         - CSS (Björn Hörmann is working on a schema for CSS, but outside 
> of the CSS WG)
>* Extensions
>         * This is a tricky case. You could define the technology to be 
> able to handle extensions, but give a way for certain classes of Products 
> to adopt a particular behavior when:
>         + it meets an extension
>                 a kind of very strict parser. The spec and only the spec, 
> no extension.
>         + it meets an extension which doesn't respect the mechanism 
> defined for extension. For example, a CSS parser which will choke on
>                 sexy-circle
>         when it should be
>                 -sexy-circle, because the spec has defined 
> "-vendor-property" for the way to create syntax extension.
>                 For example, should a user agent ignore every unknown 
> features, for example, like in HTML 4.01 and only display the content of 
> the element?
>* Contradiction with other specifications.
>         * For example some technology might redefine the default behavior 
> of another technology. For instance, HTML 4.01 and HTTP 1.0, HTML 4.01 
> defines iso-8859-1 for HTTP transaction by default when HTTP 1.0 defines 
> us-ascii. Is HTML 4.01 in this manner an authorized extension of HTP 1.0?
>         The consequences on error handling is : What a user agent 
> supporting HTML 4.01 and HTTP 1.0 in the absence of encoding information 
> should do ?
>* Conformance
>         * Error Handling is tightly joined to Conformance. A product is 
> conformant not only because it has the adequate positive reaction to, for 
> instance, a markup, but also because it has the correct behavior when 
> something wrong is happening.
>Karl Dubost -
>W3C Conformance Manager
>*** Be Strict To Be Cool ***

Received on Friday, 2 July 2004 19:36:22 UTC