Re: [SVGMobile12] Error handling is a "SHOULD"?

Hi Ian,

The error handling sections of the svg specification has gone through
quite some rework lately and we believe the current version address your
concerns. Below is the new wording of section C.3 but we hope you can
have a look at all the entire appendix C when the new version of the
spec is published. Regarding your reply below it appears that the basis
of your opinions on this matter is: "Most SVG UAs today seem to use
error recovery with no error indication at all, ..." This might or might
not be true but to prevent such behavior in the future the spec now
clearly requires error indication in order for a UA to be conformant.
---

C.3 Error processing


A conforming SVG User Agent must process errors in the following manner.

There are various scenarios where an SVG document fragment must be
considered technically in error:

*	When the content is not well-formed according to the XML 1.0 or
XML 1.1 specifications [XML11 <http://www.w3.org/TR/xml11> ] 
*	When the content is not namespace-well-formed according to the
Namespaces in XML 1.1 specification [XML-NS
<http://www.w3.org/TR/xml-names11/> ] 
*	Other situations that are described as being in error
<http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/p
ublish/intro.html#TermInError>  in this specification 

A document can go in and out of error over time. For example, document
changes from the SVG DOM
<http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/p
ublish/svgudom.html>  or from animation
<http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/p
ublish/animate.html>  can cause a document to become in error and a
further change can cause the document to become correct again.

When a document is in error the User Agent shall provide a highly
perceivable indication of error. 

Because of situations where a block of scripting changes might cause a
given SVG document fragment to go into and out of error, error
processing shall occur only at times when document presentation (e.g.,
rendering to the display device) is updated. 
---

Thanks for your feedback
/The SVG WG
  

 

On Tue, 20 Sep 2005, Jon Ferraiolo wrote:
> 
> This is the SVG Working Group response to your comment found at:
>   http://lists.w3.org/Archives/Public/www-svg/2005May/0144.html
> 
> With more recent versions of the SVG spec, we have changed the wording
and
> believe it addresses the problems that have been identified. It now
says:
> 
> -------------------
> 
> When a document is in error, the User Agent shall provide a highly 
> perceivable indication of error. The following error handling behavior

> represents a recommended approach that User Agents may choose to 
> implement: [...]
 
Are user agents also allowed to (in addition to showing a "highly 
perceivable" indication of error, such as, I assume, an entry in the 
browser's error console), make error recovery attempts?
 
Most SVG UAs today seem to use error recovery with no error indication
at 
all, which has led to significant amounts of SVG content having errors 
(most commonly errors as serious as missing namespaces). This content 
renders in UAs because they have all been reverse-engineering each
other's 
error recovery rules (I am aware of this having occured several times in
a 
couple of UAs, and it seems safe to assume it has happened with other
UAs 
too). Could the working group please clarify whether this behaviour is 
acceptable or not? If it is acceptable, could the working group please 
specify how a UA should recover for each case of the document being in 
error? This would avoid requiring UA vendors to reverse engineer other 
UAs, a situation that has led to the current Tag Soup mess with HTML.
 
 
> We did not feel it was appropriate to define a required approach to 
> error handling because implementation experience shows that this is a 
> difficult implementation area
 
On the contrary, it is my opinion that it is specifically with the 
difficult implementation areas that the implementors need the most 
guidance!
 
 
It is therefore my opinion that this does not address my concerns.
 
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'