Re: [SpecGL Draft] D5 Error Handling

Le mer 30/06/2004 ŗ 22:07, Karl Dubost a ťcrit :
> * 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.

Note that you can have an invalid syntax, even if there is no formal
language that describes the said syntax; it's easier to check whether
the syntax is followed when it is formally described, but that's not a
necessity.

>  For example
> 	- XSLT
> 	- CSS (BjŲrn HŲrmann is working on a schema for CSS, but outside of 
> the CSS WG)

(which doesn't prevent to identify "invalid" XSLT or CSS style sheets)

> 
> * 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

(actually, it won't choke, since CSS "forward compatible parsing" theory
says to just ignore it)

> 	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?

(see mustIgnore vs mustUnderstand in the wiki topic
http://esw.w3.org/topic/ErrorHandling)

> * 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.

The story is actually different: the HTTP protocol defines iso-8859-1 as
the default encoding for text/* when no encoding is specificed; the HTML
spec says to ignore that and that you must specify an encoding.
http://www.w3.org/TR/1999/REC-html401-19991224/charset.html#spec-char-encoding
http://www.ietf.org/rfc/rfc2854.txt (section 6)

>  Is HTML 4.01 in this manner an authorized extension 
> of HTTP 1.0?

definitely not; contradicting a specification you rely doesn't make you
an extension :)

> 	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 
> ?

"In addition to this list of priorities, the user agent may use
heuristics and user settings. For example, many user agents use a
heuristic to distinguish the various encodings used for Japanese text.
Also, user agents typically have a user-definable, local default
character encoding which they apply in the absence of other indicators."
http://www.w3.org/TR/1999/REC-html401-19991224/charset.html#spec-char-encoding

> * 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.

Good point, indeed.

Dom
-- 
Dominique HazaŽl-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org

Received on Friday, 2 July 2004 05:39:21 UTC